ASP.NET MVC - Respository/Service/Controller
Думаю, да. Так как указатель функции использует подпись для идентификации, базироваться/получать поведение полагалось бы на любой объект, Вы обратились к нему.
6 ответов
Если у вас есть уровень обслуживания, и вы используете его таким образом, чтобы абстрагировать бизнес-логику от репозитория (как вы должны с уровнем обслуживания), тогда нет, ваши контроллеры должны только звонить в методы обслуживания. Затем уровень сервиса будет соединением с репо.
В дополнение к ответу Мэйо: модель - это классы данных, которые будут передаваться по всему приложению (репо, сервис и UI / контроллеры), поэтому UI / веб-уровень должен: работать с ними так же, как и с другими уровнями.
Я думаю, что если вы реализуете уровень обслуживания в контексте определения Фаулера и современных адаптаций aspnet mvc , тогда у вас должны быть действия вашего контроллера, разработанные как очень маленькие и легкие методы, вызывающие «мясистые» бизнес-логика из уровня обслуживания.
РЕДАКТИРОВАТЬ: Я не совсем понял: я не говорю, что наличие уровня обслуживания - единственный вариант, я просто пытаюсь ответить на часть вопрос, относящийся к случаю, когда вы используете уровень обслуживания. Согласитесь, уровень обслуживания не всегда необходим, особенно для небольших проектов.
Контроллер интерпретирует вводимые пользователем данные и подготавливает модели для использования в представлении, как я это понял. Некоторые люди действительно серьезно относятся к удалению каждого бита логики из моделей, но я не такой уж анальный по этому поводу.
ИМХО, лучший вариант - использовать DI для доступа к вашему репозиторию изнутри контроллера.
Вам не всегда нужен уровень обслуживания - в простых ситуациях это просто чрезмерная разработка решения. Контроллер может вызывать репозиторий. Но если вы видите, что ваши контроллеры раздуваются логикой, или вы повторяете себя в действиях контроллера, то посмотрите на размещение службы между контроллером и репозиторием и переместите часть логики с контроллера на другой уровень сервиса.
Я согласен с @ Sosh насчет чрезмерной инженерной мысли. Но я обнаружил одно большое преимущество от того, что контроллер проходит через службу, в том, что когда приходит время повторно использовать эту службу по сети через SOAP / REST, ваша работа по рефакторингу минимальна. Имейте в виду, что это нарушает YAGNI, и он думает о будущем (в некоторой степени).
Но опять же - после прочтения последней книги Джеффри Палермо - MVC In Action , у него есть контроллер с нулевым логическим разговором. напрямую с репозиторием, и он отлично работает.
Все примеры, с которыми я работал, похоже, предполагают, что контроллер должен работать с моделью.
Тем не менее, я слышал, что некоторые авторы предполагают, что модель состоит из все, от бизнес-логики до репозитория данных (в отличие от классов бизнес-объектов, которые многие считают моделью).
Лично я бы попытался сохранить его чистым / согласованным, заставив контроллер работать с классами, которые работают с репозиторием - но я не думаю, что есть строгое правило против этого.
Уровень обслуживания - это, по сути, api для вашей бизнес-логики / бизнес-модели. Например, у вас может быть какой-то метод, который позволяет привлечь вашего «лучшего клиента». Затем уровень обслуживания делает то, что ему нужно, - запрашивает репозиторий, выполняет необходимую логику и т. Д. И возвращает клиента. В таких случаях вам всегда следует проходить через уровень сервиса.
Иногда вы просто извлекаете объект, который может быть в вашей модели представления, но не в бизнес-модели. Конечно, вы можете добавить оболочку вокруг репозитория на уровне сервиса, но тогда вы рискуете запутать то, для чего предназначен ваш уровень сервиса, и заполнить его бессмысленными вещами. В подобных случаях я не вижу вреда в том, чтобы сразу обратиться к хранилищу.