Доменные объекты, DTO и модели просмотра - PullRequest
15 голосов
/ 16 марта 2011

У меня есть приложение ASP.NET MVC 2 с моделью домена POCO и уровнем хранилища NHibernate. Моя доменная модель не знает о моих моделях представления, поэтому я использую automapper для перехода от viewmodel к сущности и наоборот.

Когда я представил WCF в своем проекте (позднее требование), я начал сталкиваться с отключенными объектами. То есть я извлекаю сущность из базы данных с помощью NHibernate, и после того, как эта сущность сериализуется, она отключается, и каждая дочерняя коллекция загружается независимо от того, планирую ли я использовать ее, то есть я выполняю много ненужной работы с базой данных.

После прочтения этого я вижу, что настоятельно рекомендуется не раскрывать свои сущности за пределами вашего доменного проекта, и вместо этого вам следует использовать DTO.

Я вижу причину этого, но мне сложно понять, как это реализовать.

Могу ли я отобразить из viewmodel в DTO в ASP.NET MVC, отправить DTO через уровень обслуживания и отобразить из DTO в сущность на уровне обслуживания? Где я должен определить свои DTO?

Ответы [ 4 ]

15 голосов
/ 16 марта 2011

Мне нравится, когда мой уровень обслуживания хранит сущности, инкапсулированные в нем, и возвращает / получает только DTO.Я храню сервисные контракты, а также DTO в отдельной сборке, на которую ссылаются и проект MVC, и ссылка на реализацию Сервиса.

Внутри реализации сервисного вызова сервис отображает dto на сущности, затем выполняет взаимодействие с репозиториями.и другие сущности, как это необходимо.

В проекте app / mvc я иногда становлюсь ленивым и просто использую DTO в качестве моделей для определенных действий (особенно CRUDy).Если мне понадобится проекция или что-то в этом роде, я создам модель представления и конвертирую между DTO и моделью представления с помощью автоматического обработчика и т. Д.

То, насколько уязвимы ваши сущности, является предметом многих споров.Некоторые люди проталкивают их до уровня представления / приложения.Я предпочитаю держать их на уровне обслуживания.Я обнаружил, что, когда сущности покидают сервисный уровень, вы обнаруживаете, что делаете вещи типа бизнес-логики в любом месте, где они взаимодействуют, вещи, которые, вероятно, должны находиться в службе.

2 голосов
/ 16 марта 2011

Я отношусь к своим DTO как к ViewModels, потому что уровень UI (приложение MVC) запрашивает их. Вы можете пойти Entity -> DTO -> ViewModel, но я думаю, что это больше, чем инжиниринг, если единственным потребителем вашей услуги является приложение MVC. Если каким-то образом DTO будут фактически использоваться для данных, а не просто для экранных спецификаций, то вам, вероятно, следует использовать дополнительное отображение.

Я также просто возвратил сущности из своего слоя WCF и позволил автоматически сгенерированным прокси-объектам на клиенте быть DTO. Объекты почти становятся DTO из-за прокси-классов, и бизнес-логика не переходит к клиенту.

И, конечно, все это "зависит" от ваших архитектурных целей. Этот вопрос является пограничным субъективным и аргументным ИМХО.

1 голос
/ 16 марта 2011

Мне нравится определять DTO в проекте MVC, а затем создавать методы расширения для преобразования из сущности домена в DTO (и наоборот).

Преобразование будет выполняться в функциях mvc.

0 голосов
/ 20 декабря 2011

Я только что написал пост о том, как обойти все эти преобразования DTO <-> DO. Может быть, вы проверите это http://codeblock.engio.net/?p=17

...