Как смоделировать и обработать презентацию DTO к краткому обзору от сложной модели предметной области?
Привет я разрабатываю приложение, которое должно работать со сложным использованием модели предметной области, в спящем режиме. Это приложение использует Spring, MVC и использование объектов области на уровне представления очень грязны, таким образом, я думаю, что должен использовать DTO, которые переходят в и от моего уровня служб так, чтобы они соответствовали тому, в чем я нуждаюсь в своих представлениях. Теперь позволяет, предполагают, что у меня есть объект CarLease, свойства которого не являются простыми примитивами Java, но он составлен с другими объектами, любят, Делают, Моделируют, и т.д.
public class CarLease {
private Make make;
Private Model model;
.
.
.
}
большинство свойств находится этим способом, и они - выбираемое использование выпадающие выборы на представлении jsp, каждый отправит назад идентификатор на контроллер.
Теперь рассматривая некоторые стандартные варианты использования: создайте, отредактируйте, дисплей
Как Вы пошли бы о моделировании презентации DTO, который будет использоваться в качестве объектов поддержки формы и коммуникации между уровнями представления и уровнями служб??
Вы создали бы другой DTO для каждого случая (создайте, отредактируйте, дисплей), Вы сделали бы DTO для сложных атрибутов? раз так, где Вы перевели бы идентификатор в объект?
как и где Вы обработали бы проверку, блок DTO/домена, что Вы возвратите из методов уровня служб? (создайте, отредактируйте, доберитесь),
Как Вы видите, я теперь я извлеку выгоду путем разделения моего представления от объектов области (очень сложный с большим количеством материала, в котором я не нуждаюсь.), но мне нелегко находить любые примеры реального мира и лучшие практики для этого. Мне нужно некоторое руководство архитектуры сверху донизу, имейте в виду, что я буду использовать Spring MVC в случае, если это может усилить на Вашем anwser.
заранее спасибо.
3 ответа
Если говорить о том, чего это стоит (я разрабатываю на C# .net - но принципы, надеюсь, все еще будут полезны для вас), я определил кучу типов (DTO), которые я использую для обмена данными между бизнес-уровнем и уровнем данных; и у меня есть более одного типа на объект домена / сущность. Они определены как простые классы.
Каждый из них создается с учетом конкретной задачи, например:
- У меня есть легкий тип, предназначенный для заполнения представлений списков (много "строк", но мало "столбцов"). У меня также есть соответствующий тип коллекции, который содержит любое количество таких элементов.
- У меня есть "большой" экземпляр get, который обычно имеет все свойства рассматриваемой сущности - но только для одного ее экземпляра. Я могу иметь более одного такого экземпляра в зависимости от размера и сложности сущности в сравнении со случаями использования; а также в зависимости от того, хотите ли вы вернуть все данные, связанные с экземпляром сущности, сразу, или лениво загрузить некоторые из них при последующих запросах.
- У меня также обычно есть отдельные типы "сохранить" (новый) и "обновить" для сущности.
Каждый тип предназначен для хранения только той информации, которая важна для данной задачи. Например, "большой" вернет дату последнего изменения, но я не ожидаю этого в моих типах сохранения и обновления, потому что я заполняю их на уровне доступа к данным.
Кроме того, для моего приложения эти типы существуют в общей сборке - поэтому их можно повторно использовать между любыми уровнями, а не только между бизнес-уровнем и уровнем данных.
Архитектурная пригодность
В этом подходе нет ничего особенного, у него есть свои плюсы и минусы; что именно это такое и как они влияют на вас, зависит от многих вещей - я думаю, ваш пробег будет варьироваться, - но он определенно служит мне хорошо уже несколько лет.
Люди часто шумят о "разделении забот" - и это действительно мудрый шаг; это относится к DTO в том смысле, что они обмениваются между слоями (и сервисами, компонентами и т.д.), поэтому всегда может возникнуть некоторая двусмысленность в отношении того, где именно проводить границу.
Я придерживаюсь подхода, что если часть информации пригодна для обмена между уровнями, то, вероятно, она пригодна для обмена между любым количеством уровней - так почему бы не сделать ее доступной для всех? Это также избавляет от необходимости повторно передавать информацию, если вы просто передаете ее.
Что касается сложности - есть два способа справиться с этим:
- Использовать многословное / человекочитаемое соглашение об именовании для всех типов, чтобы вы знали, что это за вещи; неважно, сколько их - для этого и нужен intelli-sense (и документация). Чем интуитивнее, тем лучше.
- KISS - сохраняйте все простым, если можете; вам придется балансировать между разумным повторным использованием и принципом единой ответственности (SRP).
Создали бы вы DTO для сложного свойства основной сущности?
Я обнаружил, что создаю DTO по одной из двух причин:
- Есть данные, которые я знаю, что мне нужно раскрыть (push), и дизайн DTO не вызывает сомнений: он определяется данными, которые я хочу раскрыть.
- Pull: потребитель знает, чего он хочет, и DTO разрабатывается для удовлетворения этих потребностей.
Поскольку все они определены в общей сборке, ни один компонент не "владеет" ею, это заставляет вас думать с точки зрения "домена", а не компонентоцентрично; в некоторой степени это повлияет на дизайн DTO (баланс между повторным использованием и SRP).
В обоих случаях создаваемые DTO могут быть как специфичными для конкретной потребности, так и общими; например, DTO, содержащий только int и строку, не является редкостью, его можно использовать для отправки в выпадающие списки.
Большинство коллекций DTO, которые я отправляю обратно (из DAL в BL), специфичны для концепции - не общие. Я применяю очень простые правила к ним через конструкторы, которые я предлагаю: каждый аргумент обязателен. Не уверен, что это ответ на ваш вопрос "Как вы управляете сборкой и проверкой".
Идея о том, что уровень сервиса должен возвращать DTO вместо объектов EJB, в основном возникла до эры EJB3 / JPA. Во время CRUD вы действительно много выигрываете от непосредственной работы с объектами модели (также известными как сущности).
Однако вы можете извлечь выгоду из использования DTO, когда он используется для оптимизации производительности, например, когда объекты модели слишком громоздки или когда вы получаете выгоду от использования некоторых интеллектуальных объединений для агрегирования данных модели.
Поэтому, если вы не разрабатываете SOA, я бы не рекомендовал работать с DTO для операций CRUD.
Рассматривали ли вы принцип разделения ответственности за запросы команд (CQRS)? Вкратце, это архитектурный принцип, пропагандирующий использование отдельных компонентов для операций чтения и изменения.
Модификации выполняются с помощью команд, отправленных в модель предметной области. Ваш NewCarLeaseDTO выглядит как команда CreateNewCarLeaseCommand. Они содержат все данные, необходимые для конкретной операции.
С другой стороны, чтение (либо для списка, либо для подробностей) выполняется непосредственно из базового хранилища данных (базы данных SQL). Здесь есть много возможностей, от наличия одного и того же хранилища данных, поддерживающего части чтения и записи, до наличия двух независимых хранилищ данных, подключенных через инфраструктуру публикации / подписки.
При использовании последнего (два хранилища) подхода к стороне чтения многие (например, Уди Дахан) выступают за использование так называемых постоянных представлений. Это означает хранение данных непосредственно в форме, доступной вашим представлениям. Преобразование (денормализация) выполняется при синхронизации после обновления модели.
Если вы хотите узнать больше о CQRS, я рекомендую прочитать Уди Дахана и Грега Янга.