Доменные сущности, DTO и модели просмотра
У меня есть ASP.NET приложение MVC 2 с моделью домена POCO и уровнем репозитория NHibernate. Моя модель домена не знает моих viewmodels, поэтому я использую automapper для перехода от viewmodel к сущности и наоборот.
когда я представил WCF в свой проект (позднее требование), мне пришлось иметь дело с отключенными объектами. То есть я извлекаю сущность из базы данных с помощью NHibernate, и как только эта сущность сериализуется, она отключается и каждый дочерний элемент коллекция загружается независимо от того, планирую ли я ее использовать, что означает, что я делаю много ненужной работы с базой данных.
прочитав об этом, я вижу, что настоятельно рекомендуется не выставлять свои сущности за пределами вашего доменного проекта, и вместо этого вы должны использовать DTOs.
Я вижу причину этого, но у меня возникли проблемы с тем, как ее реализовать.
я сопоставляю viewmodel с DTO в ASP.NET MVC, отправить DTOs через службу слой и карта от DTO к сущности в слое сервиса? Где я должен определить свои DTOs?
4 ответов
Мне нравится, чтобы мой уровень сервиса содержал объекты, инкапсулированные в нем, и возвращал/получал только DTOs. Я храню контракты на обслуживание, а также DTO в отдельной сборке, на которую ссылаются как проект MVC, так и реализация службы.
внутри реализации вызова службы служба сопоставляет dto с сущностями, а затем выполняет взаимодействие с репозиториями и другими сущностями по мере необходимости.
на проекте app / mvc я иногда буду лениться и просто использование ДТО в качестве моделей для определенных действий (особенно CRUDy из них). Если мне нужна проекция или что-то в этом роде, я сделаю viewmodel и конвертирую между DTO и viewmodel с automapper и т. д.
Как подвергаются ваши сущности является предметом больших дебатов. Некоторые люди будут толкать их до самого уровня представления/приложения. Я предпочитаю держать их на уровне сервиса. Я нахожу, что когда сущности покидают уровень обслуживания, вы обнаруживаете, что делаете бизнес-логику типа везде, где они взаимодействуют, вещи, которые, вероятно, должны находиться в службе.
Я рассматриваю свои DTOs как ViewModels, потому что уровень пользовательского интерфейса ( приложение MVC ) запрашивает их. Вы можете пойти Entity - > DTO - > ViewModel, но я думаю, что это над инженерией, если единственным потребителем вашей услуги является приложение MVC. Если каким-то образом DTOs будет использоваться для данных, а не просто спецификации экрана, то вы, вероятно, должны использовать дополнительное сопоставление.
Я также просто вернул сущности из моего слоя WCF и позволил автоматически сгенерированным прокси-объектам на клиент будет DTO. Сущности почти становятся DTOs из-за прокси-классов, и никакая бизнес-логика не переходит к клиенту.
и, конечно же, это все "зависит" от ваших архитектурных целей. Этот вопрос является пограничным субъективным и аргументативным ИМХО.
Мне нравится определять DTO в проекте MVC, а затем создавать методы расширения для преобразования из сущности домена в DTO (и наоборот).
преобразование будет происходить в функциях mvc.
Я только что написал сообщение о способе обойти все это преобразование DTO DO. Может быть, вы проверить его http://codeblock.engio.net/?p=17