Домен против DTO и ViewModel - как и когда их использовать?

В многоуровневом проекте с уровнем уровня домена (DL)/Business (Service) Layer (BL)/Layer Layer (PL) лучший подход для доставки объектов на уровень презентации?

DO => Domain Object;
DTO = Domain Transfer Object;
VM => View Model;
V => View;

Вариант 1:

DL => DO => BL => DTO => PL => VM => V

Этот вариант, по-видимому, является лучшей практикой, но также кажется тяжелым для работы.

Вариант 2:

DL => DO => BL => DTO => PL => V

Этот вариант кажется не очень хорошей практикой, но поскольку DTO почти идентичен виртуальной машине, мы можем передать ее непосредственно в представление, и это менее болезненно для реализации и обслуживания.

Является ли эта опция надежной и для нескольких макетов, например для мобильных устройств, мне может понадобиться меньше информации из BL, поэтому для этого конкретного макета мне понадобится другая виртуальная машина?

Ответы

Ответ 1

OK, чтобы передать DTO в представление. Если вам нужно изменить или улучшить DTO, тогда создайте ViewModel. Общий сценарий - добавить ссылки. Также хорошо, чтобы ViewModel ссылался на DTO как сложное свойство.

Ответ 2

Если у вас будут разные представления, требующие разных данных от вашего D, это звучит так, как будто вы можете использовать разные модели просмотра для них и сопоставить их с Dto.

Одна из идей, стоящих за этим, заключается в том, чтобы позволить большую свободу менять свою модель представления, зная, что это не повлияет на любую другую часть вашего приложения. Если ваше Dto используется в нескольких представлениях, каждое изменение вашего Dto потребует от вас проверки каждого вида.

Ответ 3

См. здесь мой ответ: fooobar.com/questions/75021/...

Вы говорите: Этот вариант, по-видимому, является лучшей практикой, но также кажется тяжелым для работы.

тяжелый, чтобы реализовать, возможно, juste несколько строк кода, чтобы дублировать большую часть времени, но поддерживать, конечно, не.

Ответ 4

Для меня это решение основано на том, где я поставил свою логику проверки.

Сценарий №1: Добавление аннотации данных в режиме просмотра (в слое пользовательского интерфейса) значительно упрощает программирование. В основном будет отображаться один на один между DTO и моделью просмотра. В таких случаях вариант 1 хорош. DL = > DO = > BL = > DTO = > PL = > VM = > V

Сценарий №2) Если проверка не привязана к ViewModels, то DTO заменяется ViewModel, а ViewModel находится в бизнес-слое. DL = > DO = > BL = > VM = > PL = > V

Сценарий №2 может быть идеальным в ситуациях, когда логика проверки находится в моделях доменов. И эти модели используются многими приложениями пользовательского интерфейса. Пользовательский интерфейс просто перечисляет ошибки в списке, заданные бизнес-слоем (хотя и не очень удобные для пользователя). Поскольку приложение претерпевает изменения бизнес-правил, мы меняем только модель домена. Снова связанные с базой данных проверки могут быть сгенерированы автоматически через EF (при использовании .net), что еще меньше возможностей для изменения.