ASP.NET MVC - репозиторий/служба/контроллер

Question

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

Answer 1

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

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

Я думаю, если вы реализуете слой услуг в контексте Fowler's definition и modern aspnet mvcadaptions, то вы должны иметь ваши действия контроллер выполнен в виде очень мелких и легких способов, называя «мясистые» бизнес-логику от вашего уровня обслуживания.

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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