Шаблон службы и репозитория и разделение проблем

Я использую шаблон проектирования уровня службы / репозитория поверх Entity Framework. Все было хорошо, пока я не захотел, чтобы запрос возвращал объединение данных о двух разных объектах.

Например, у меня есть две сущности Document и ShoppingBasketItem. Итак, теперь у меня есть две службы: DocumentService и ShoppingBasketService. Сначала я просто перечислил документы на основе поиска пользователей. Но позже я хотел выделить документы, которые уже были в корзине покупателя. Таким образом, службе документооборота теперь необходимо знать о концепции корзин для покупок.

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

Итак, мой вопрос: хороший ли это подход? Или мне, возможно, следует создать новую службу DocumentBasketService, которая обрабатывает запросы, касающиеся информации о документах и ​​корзинах для покупок?


person Leigh Ciechanowski    schedule 03.01.2013    source источник


Ответы (2)


Итак, мой вопрос: хороший ли это подход?

По-разному.

У меня есть некоторые резервы в отношении такого подхода к определению служб. Вы хотели бы достичь SoC, что было бы разумно, но я думаю, что мы должны работать над определением проблемы. Действительно ли проблема в данном случае является предметным объектом? Судя по проблемам, с которыми вы сталкиваетесь, не похоже.

Я видел эту реализацию снова и снова: в конце концов, может показаться логичным определить DocumentService, работающий с DocumentRepository. По моему опыту, они в конечном итоге перенаправляют некоторые / большинство вызовов в репозиторий напрямую и имеют огромный контракт на обслуживание, потому что в конечном итоге все, что связано с документами, попадет в DocumentService.

Если вы занимаетесь ориентацией на сервисы, решение, которое я обычно принимаю, состоит в том, чтобы мои сервисы говорили «бизнес», а не предметно, заставляя их реализовывать бизнес-кейсы, а не перекладывать их на упаковку репозитория. Тогда вы сможете достичь SoC в своих сервисах, и ваши проблемы будут связаны с проблемами бизнеса: определение этих проблем полностью зависит от ваших бизнес-кейсов, а это означает, что я не могу вам в этом помочь. OTOH, если вам действительно нужны доменные службы, этот совет совершенно бесполезен; как я уже сказал, это зависит от ваших потребностей.

Итак, универсально верный момент: пересмотрите то, что вы пытаетесь разделить, и чего вы хотите этим достичь.

person Filippo Pensalfini    schedule 03.01.2013
comment
+1. Хороший ответ. Но Я архитектор заставил меня глубоко вздохнуть, почти перестал читать и проголосовал за -1 (заставил меня подумать, вот еще один подражатель архитектора, который хочет похвастаться). В подобных комментариях нет нужды. Ваш ответ хорошо продуман и мотивирован. Так держать. - person jgauffin; 04.01.2013
comment
@jgauffin, извините, это было задумано как шутка над тем фактом, что это зависит от стандартного ответа архитектора на такие вопросы, но, видимо, он не получился правильным, поэтому я удалю его :) Тем не менее, спасибо за добрые слова. - person Filippo Pensalfini; 04.01.2013
comment
может это только я устала (или тупо);) - person jgauffin; 04.01.2013

Хм, я, возможно, придумал ответ, в котором сохраняется четкое разделение проблем.

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

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

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

person Leigh Ciechanowski    schedule 03.01.2013