Услуги и репозитории в DDD (С#)

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

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

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

Я хотел бы получить некоторое просвещение по этому вопросу.

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

UPDATE

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

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

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

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

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

ОТВЕТЫ

Ответ 1

Правда, репозиторий работает с данными (например, SQL, Webservice и т.д.), но это единственное задание. CRUD, ничего более. Логической логике, основанной на хранимой процедуре, нет места.

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

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

Ответ 2

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

Ответ 3

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

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

OrderService - возьмите корзину, преобразует ее в заказ и обрабатывает процесс оплаты и т.д.

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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