Услуги и хранилища в DDD (C #)

Question

Как Services и Repositories связаны друг с другом в DDD? Я имею в виду, я читал о DDD в течение последних 2 дней, и везде, где бы я ни был, всегда есть слой Service и всегда есть слой Repository. Как они различают или дополняют друг друга?

Из того, что я прочитал, не является ли Repository слой, ответственный за делегирование взаимодействия между приложением и данными?

Итак, зачем нужен слой Service, если он должен реализовать Repository для взаимодействия с данными, даже если Repository, вероятно, уже реализует методы, необходимые для этого?

Буду признателен за некоторое понимание этого вопроса.

P.S. Не знаю, поможет ли это кому-нибудь, но я работаю с приложением ASP.NET MVC 2, в котором я пытаюсь реализовать шаблон Repository. Я только что закончил реализацию шаблона Dependency Injection (впервые) ...

UPDATE

Хорошо, с таким количеством ответов, я думаю, я понимаю, в чем разница. Итак, для обзора (поправьте меня, если я ошибаюсь):

• Слой Repository взаимодействует только с одним объектом из базы данных или ORM, IEmployeeRepository -> Employee.

• Слой Service инкапсулирует более сложные функциональные возможности для объектов, возвращаемых из Repositories, одного или нескольких.

Итак, у меня есть подвопрос. Считается ли плохой практикой создание абстрактных объектов для отправки в мои представления? Например, AEmployee (A для abstract, потому что для меня I означает interface), который содержит свойства Employee и X или X?

Собственно, еще один подвопрос. Если слой Service можно считать настроенным для приложения, нужно ли его реализовать с помощью интерфейса?

Answer 1

Служба будет использовать хранилище для извлечения сущности, а затем вызывать методы для него (сущности) для выполнения команды / задачи.

Answer 2

Да, репозиторий работает с данными (т. Е. SQL, Webservice и т. Д.), Но это только работа * .Операции CRUD, не более того.Нет места для бизнес-логики на основе хранимых процедур.

Служба (или уровень бизнес-логики) обеспечивает функциональность. Как выполнить бизнес-запрос (т. Е. Рассчитать зарплату), что нужно сделать.

О, и это действительно хорошая книга DDD: http://www.infoq.com/minibooks/domain-driven-design-quickly

Answer 3

В качестве конкретного примера приложение Корзина может иметь следующие службы:

ShoppingCartService - управляет корзиной товаров с поддержкой добавления / удаления / обновления и т. Д.

OrderService - взять корзину, преобразовать ее в заказ, обработать платеж и т. Д.

каждая из этих служб должна использовать «источник данных» для операций CRUD.Здесь шаблон Repository пригодится, поскольку он абстрагирует загрузку и сохранение данных в и из источника данных, будь то база данных, веб-служба или даже кэш в памяти.

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

В приведенном выше примере ваш прототип может начинаться со следующего:

• FakeCustomerRepository
• FakeAddressRepository
• FakeCartRepository
• FakeCartLineItemRepository
• FakeOrderRepository
• FakeOrderLineItemRepository

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

• SQLCustomerRepository
• SQLAddressRepository
• SQLCartRepository
• SQLCartLineItemRepository
• SQLOrderRepository
• SQLOrderLineItemRepository

Answer 4

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

Answer 5

Не существует золотого стандарта, определяющего сервис или хранилище.В моих приложениях хранилище - это (как вы говорите) интерфейс в базе данных.Сервис имеет полный доступ к репозиторию, но сервис предоставляет потребителям подмножество функций.

Думайте о репозитории как о более низком уровне.Хранилище должно предоставлять множество способов доступа к базовой базе данных.Служба может объединять обращения к хранилищу с другим кодом, который имеет смысл только на уровне кода (т.е. не в базе данных), например, доступ к другому состоянию в приложении или проверка / бизнес-логика, которую нелегко применить вбаза данных.