Реализация уровня сервиса в архитектуре MVC

Как обычно реализовать уровень сервиса в архитектуре MVC? Это один объект, который обслуживает все запросы к базовым бизнес-объектам? Или это больше похоже на объект, который обслуживает разные объекты службы, которые в свою очередь взаимодействуют с бизнес-объектами?

Итак:

  • Контроллер → Сервис → getUserById() или:

  • Контроллер → ServiceManager → getUserService() → getUserById()

Кроме того, если последнее более подходит, настройте этот объект ServiceManager в бутстрапе? Другими словами, зарегистрируйте различные службы, которые вам понадобятся для вашего приложения, менеджеру службы в начальной загрузке?

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

Спасибо заранее.

ОТВЕТЫ

Ответ 1

То, как я прочитал этот вопрос, действительно есть две вещи, на которые нужно ответить:

A) Я бы предпочел разделить "Сервис" на "CustomerService" и "OrderService", другими словами, сгруппированные по понятиям домена.

B) Во-вторых, я бы использовал инъекцию зависимостей, чтобы получить надлежащую службу напрямую там, где она мне нужна, поэтому я в основном использую alt 1. Добавленная абстракция в альтернативе 2 не дает мне никакой дополнительной ценности, поскольку контейнер IoC важная часть.

Ответ 2

Я лично предпочитаю # 2, и да, он обычно настраивается в бутстрапе, или зависимости будут разрешаться с использованием какого-то контейнера IoC, чтобы предоставить вам конкретные конкретные экземпляры.

Я также хотел бы прокомментировать, и да, я понимаю, что это, вероятно, более личное предпочтение. Попытайтесь избежать использования слоя "Сервис" для этих объектов. ссылайтесь на них как на репозитории или на что-то еще. если вы используете сервис, этот термин становится перегруженным... потому что тогда разработчики похожи: "вы имеете в виду, как отдых или услуга wcf?". поверьте мне, мы сделали это с недавним проектом, и мы все время путаем себя, когда мы говорим о том, где делать изменения кода: -P