Полезны ли репозитории без доменного дизайна?

Question

Предполагая, что мое приложение не требует полной настройки DDD, хранилища все еще будут полезны?Мне нравится, как они защищены от деталей реализации (таких как использование Entity Framework).Однако хранилища, как правило, привязаны к совокупным корням (для меня эта концепция все еще является святым Граалем).

Я полагаю, что вопрос также можно поставить так: если у меня типичное трехуровневое приложение,с фасадом бизнес-уровня, состоящим из классов «логической группировки», основанных на функциональности (а не агрегированных корнях, как в DDD), таких как TradingManager и ContactsManager, имеет смысл также создавать репозитории «логической группировки».Или, возможно, объект доступа к данным, который, как я считаю, похож на репозиторий без требования совокупного корня.Конечно, у меня все еще будет Модель (EF POCO), которая будет передаваться между уровнями вверх и вниз.

Кроме того, будет ли то, что я только что описал, подходом сценария транзакции?Это конечно не DDD и не Active Record.Я даже не уверен, существует ли активная запись с EF4, как с Nhibernate.

Я пытаюсь понять, как другие структурируют n-слойные приложения, когда они не следуют DDD.

Answer 1

Как вы уже намекали, это звучит так, как будто вы больше ориентированы на DAO.Я думаю, что DAO очень полезны в не-DDD проектах, где вы хотите полностью абстрагировать технологию уровня данных.

Что касается сценария транзакции, то он ортогонален вашей структуре уровня данных.Сценарий транзакции подразумевает, что каждая бизнес-операция группируется в процедурный вызов.Пример: шаблон сценария транзакции часто используется в вызовах службы WCF на стороне сервера, причем каждый метод службы следует шаблону сценария транзакции.Подумайте об этом так: в сценарии транзакции настоящая бизнес-логика не в объектах, а написана прямо в вызове процедуры сценария транзакции.Общая бизнес-логика может совместно использоваться скриптами транзакций, но обычно это делается статическими методами, помощниками и т. Д., А не через «чистый» ОО.*

Очевидно, что первый пример вовсе не ОО.Второй пример в большей степени основан на объектах, чем OO, поскольку вся бизнес-логика происходит в вызове MailService.Третий пример - традиционный ОО.В служебном вызове происходит только поток управления;вся бизнес-логика обрабатывается в методе User.IsValid ().

Все сводится к тому, куда вы помещаете бизнес-логику.

Answer 2

Как всегда ... "это зависит".: D Извините ...

Я думаю, что это сводится к принципу единой ответственности.Если все, что делает ваш DAO - это извлечение сущностей (ну, в общем, CRUD, скорее, как a DbContext), и ничего больше ... тогда да, катитесь с одним.Если вы начнете обнаруживать, что у вас есть настраиваемая логика для разных сущностей, вы захотите рассмотреть что-то вроде хранилища.