Архитектура S # arp: куда поместить эту доменную логику - PullRequest
Новая
       10

Архитектура S # arp: куда поместить эту доменную логику

2 голосов
/ 06 февраля 2011

re: S # arp Architecture

Небольшой вопрос о том, куда поместить определенные виды доменной логики с S # arp.Итак, представьте себе это правило домена:

При запросе определенной комнаты чата по имени верните комнату, если она уже существует, или создайте новую с таким именем и верните ее.

Это логика домена?В таком случае, как мне реализовать это в моем объекте Entity (поскольку мне кажется, что для этого нужен доступ к репозиторию)

Является ли эта логика контроллера?В таком случае, я полагаю, что достаточно просто вставить его в контроллер MVC.

Это логика доступа к данным?В этом случае я встраиваю его в объект Repository, и Contoller вызывает его.Опять же, достаточно просто.

Я считаю, что это логика предметной области, но потом я не уверен, как встроить ее в мою сущность.Поскольку сущности, кажется, не имеют доступа к репозиториям (или я что-то упустил?).

1 Ответ

3 голосов
/ 07 февраля 2011

Исходя из того, как вы это описали, я бы сказал, что это лучше всего сделать на уровне служб приложений.(слой Задачи в примере проекта WhoCanHelpMe?).Для меня это логика приложения, а не логика домена.

Для других опций:

  • Sharp разработан специально, чтобы сущности не могли получить доступ к репозиториям.(Вы найдете довольно много статей о том, почему сущности должны игнорировать постоянство.)
  • В общем, контроллеры не предназначены для непосредственного размещения какой-либо бизнес-логики - для удобочитаемости, тестируемости и т. Д.(Лично мне удобно сначала вводить логику, а затем рефакторинг.)

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

ChatRoom GetRoomByName (string name);
ChatRoom GetRoomById (int id);

, обычно GetRoomById возвращает ноль, если нет места для данного идентификатора, поэтому не слишком очевидно, что первый метод будет тихо создавать (и предположительно сохраняться?)комната, если у вас ее еще нет.

Концептуально, с DDD Быстро (p56):

Мы не должны смешивать хранилище с фабрикой,Фабрика должна создавать новые объекты, а Репозиторий должен находить уже созданные объекты.Когда новый объект должен быть добавлен в репозиторий, он должен быть сначала создан с использованием фабрики, а затем он должен быть передан в репозиторий

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

...