ASP.NET MVC - Репозиторий / Сервис / Контроллер

Question

Должен ли когда-либо Контроллер напрямую вызывать Репозиторий или он всегда должен работать через уровень сервиса? Или есть другие варианты?

Answer 1

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

В дополнение к ответу Мейо: модель - это классы данных, которые будут передаваться по всему приложению (репо, сервис и пользовательский интерфейс / контроллеры), поэтому пользовательский интерфейс / веб-уровень должен «работать» с ними так же, как и с другими уровнями.

Я думаю, что если вы реализуете уровень обслуживания в контексте определения Фаулера и современного aspnet mvc адаптаций , то у вас должны быть разработаны действия контроллера как очень маленькие и легкие методы, вызывающие «мясистую» бизнес-логику из уровня обслуживания.

РЕДАКТИРОВАТЬ: Полагаю, я не совсем понял: я не говорю, что наличие сервисного уровня - единственный вариант, я просто пытаюсь ответить на часть вопроса, относящуюся к случай, когда вы делаете уровень обслуживания. Согласитесь, уровень обслуживания не всегда необходим, особенно для небольших проектов.

Answer 2

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

Answer 3

Я бы согласился с @ Sosh по поводу чрезмерной технической точки зрения. Но я обнаружил одно большое преимущество от того, что контроллер проходит через службу, в том, что когда приходит время повторно использовать эту службу по проводной связи через SOAP / REST, ваша работа по рефакторингу очень минимальна. Имейте в виду, что это нарушает ЯГНИ, и оно думает о будущем (в некоторой степени).

Но опять же - после прочтения последней книги Джеффри Палермо - MVC в действии , у него есть контроллер с нулевой логикой, напрямую взаимодействующий с хранилищем, и он прекрасно работает.

Answer 4

Сервисный уровень - это в основном API для вашей бизнес-логики / бизнес-модели. Например, у вас может быть какой-то метод, который позволяет получить «лучшего клиента». Затем сервисный уровень делает то, что ему нужно, для запроса к хранилищу, выполнения любой логики и т. Д. И возврата клиента. В таких случаях вы всегда должны проходить уровень обслуживания.

Иногда вы просто получаете объект, который может быть в вашей модели представления, но не в бизнес-модели. Конечно, вы можете добавить обертку вокруг хранилища на уровне сервиса, но тогда вы рискуете испортить то, для чего предназначен ваш уровень сервиса, и заполнить его бессмысленными вещами. В таких случаях я не вижу вреда в том, чтобы идти прямо по хранилищу.

Answer 5

Контроллер интерпретирует пользовательский ввод и подготавливает модели для использования View, как я понял. Некоторые люди очень серьезно относятся к удалению каждой логики из моделей, но я не настолько анален по этому поводу.

Лучший вариант IMHO - использовать DI для доступа к вашему хранилищу из контроллера.

Answer 6

Все примеры, с которыми я работал, указывают на то, что контроллер должен работать на модели.

Тем не менее, я слышал, что некоторые авторы предполагают, что модель состоит из всего: от бизнес-логики до хранилища данных (в отличие от классов бизнес-объектов, которые многие считают моделью).

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