Должен ли я всегда использовать сервис или я могу использовать репозитории напрямую? - PullRequest
Новая
       4

Должен ли я всегда использовать сервис или я могу использовать репозитории напрямую?

9 голосов
/ 20 января 2012

Должен ли я всегда проходить через службы, когда я пытаюсь следовать DDD?

Или я могу использовать хранилище напрямую для получения объекта домена?

Ответы [ 3 ]

8 голосов
/ 21 января 2012

Лично мне не нравится видеть репозитории в контроллерах или на уровне представления в целом.Но я видел это много раз, и в этом нет ничего плохого в контексте DDD.

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

2 голосов
/ 23 января 2012

Или я могу напрямую использовать хранилище для получения объекта домена?

Вы определенно можете.Это точно цель репозиториев.Интересно, какой сервис вы бы использовали для этого (за исключением конкретного контекста архитектуры на основе SOA или веб-сервисов).

0 голосов
/ 12 декабря 2012

После завершения моего первого проекта, структурированного по принципам DDD: D, я обнаружил, что полезно иметь как доменные службы, так и репозитории, доступные для уровня приложений.

Ключевая точка: Прикладным уровнем может быть ваши службы WCF или код в ваших веб-службах, если вы используете эту архитектуру. Все зависит от вашей реализации. Если это соответствует вашей реализации, уровень приложения может совпадать с уровнем представления, поэтому код уровня приложения находится в ваших контроллерах или в коде веб-форм.

Хранилища функционируют как коллекции в памяти. На прикладном уровне код должен выглядеть так, как будто вы просто используете любую старую коллекцию.

Доменные службы функционируют больше как процессоры или средства доступа к информации, которая никогда не будет обновлена, может быть обработана, но не обновлена ​​напрямую. На уровне приложения код должен выглядеть так, как будто вы просто используете любой старый веб-сервис.

При этом я объясню больше на нескольких примерах:

Хранилища

Мои репозитории фактически наследуются от универсальной коллекции, набранной с помощью созданного мной объекта реализации, который объединяет ключ базы данных и бизнес-модель вместе. Используя этот подход, я могу определить индексатор в моем интерфейсе, например 

BusinessObject this[int index];

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

IBusinessObjectRepository repository = new SqlBusinessObjectRepository(sqlString);
BusinessObject obj = repository[0]; //Get first object in the list.
//Make some changes to the business object by setting properties or calling methods to process business logic.
repository[0] = obj; //Save the object back to the database.

Услуга

Я использую службы для извлечения списков сущностей и объектов-значений, которые я не собираюсь редактировать по отдельности, и в моем случае они используются только как доступные выборки или значения при вызове методов в совокупном корне. Обычно я кеширую эту информацию на веб-сервере. Это не единственное использование доменной службы, только мой пример. Код прикладного уровня все еще остается относительно простым. 

IBusinessService service = new ImplBusinessService(implementationArgs);
List<BusinessObject> objsToCache = service.GetBusinessObjects();
//cache the objects on the web server.

В заключение и из моего понимания принципов DDD прикладной уровень должен иметь возможность доступа к бизнес-объектам из сервисов или репозиториев. Выбор между ними сводится к тому, что лучше всего подходит в рамках модели предметной области.

...