Некоторые рекомендации Asp.NET MVC2 для управления контроллерами жира на уровне бизнес-службы

Мои контроллеры становятся большими и из-под контроля.

Типичный контроллер выполняет следующие действия:

  • Определяет, имеет ли данный пользователь доступ к данному ресурсу.
  • Он проверяет ViewModel.
  • Переводит ViewModel в DTOModel для сохранения.
  • Он вызывает репозитории для обновления/создания новых объектов и связанных с ними других новых объектов.
  • Он обращается к данным в нескольких вспомогательных классах репозитория
  • Он проверяет, узнают ли пользователи.
  • Он вызывает помощников для отправки писем
  • Он регистрирует данные в базе данных через другие объекты репозитория
  • и т.д...

Короче говоря, они ORCHESTRATE много чего. Я хотел бы переместить все на уровень сервисов, но на самом деле не видел каких-либо реализованных шаблонов в образцах кода, которые мне нравятся. Я посмотрел на некоторые из проектов с открытым исходным кодом, таких как KiGG, Oxite, codecampserver и т.д.... но никто из них действительно не решает проблему сокращения моих контроллеров. Я бы хотел избежать передачи большого количества материалов HTTPContext, но, возможно, это невозможно.

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

Спасибо за некоторые ссылки и предложения

5 ответов

Я не знаю каких-либо реальных примеров, чтобы показать свою голову, потому что я думаю, что придумал мой контроллер MVC-приложений → сервис → схему распределения репозитория на основе случайных вопросов и ответов, которые я нашел при просмотре SO.

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

Мой сервисный уровень объединяет один класс обслуживания для каждой бизнес-единицы. Поэтому, если у моего приложения есть проекты, и у каждого проекта есть человек, у меня будет класс ProjectService и класс PersonService.

Основываясь на вашем описании работы ваших контроллеров, мои действия с контроллером работают следующим образом.

1) Получите текущую информацию о пользователе и вызовите соответствующий метод авторизации класса обслуживания. Поэтому, если пользователь пытается изменить детали проекта, я передам идентификатор пользователя и идентификатор проекта методу ProjectService AuthorizeUser. Это означает, что если я изменю способ авторизации пользователей для проектов, мне нужно изменить метод авторизации, а не каждый контроллер.

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

3) Регистрация всех действий происходит на уровне сервиса. Это может быть автоматическим на основе представленного действия (попытка сохранить объект в db), или ваш контроллер может явно вызвать сервисный уровень для регистрации действия.

Все дело в том, чтобы объединить общую функциональность в легко поддерживаемый уровень. Если вы измените способ преобразования вашей модели представления в DTO, ОЧЕНЬ легко узнать, где внести изменения и сделать это один раз. Если вам нужно изменить свой журнал, пользовательский доступ или даже если вы хотите изменить способ получения определенных данных из репозиториев, это одна простая область для изменения, а не поиск всех ваших контроллеров и их изменение напрямую.

Изменить. Это не позволяет контроллерам быть небольшим, так как на самом деле они содержат только несколько вызовов на уровне сервиса и выполняют его (авторизация, выполнение действий, просмотр представления). Конец редактирования

Наконец, на веб-сайте asp.net есть учебное пособие для проверки на уровне сервиса. Этот учебник можно найти здесь.


Вы должны проверить этот великий сеанс MVCConf о Ввод ваших контроллеров на диету.


Мне кажется, что вы полагаетесь на свой контроллер, чтобы играть слишком много ролей.

При проектировании контроллера я обычно думаю об этом как о контроле доступа к одному типу ресурсов. Это означает, например, если бы я создавал эту страницу, которую вы сейчас читаете, где вы можете публиковать ответы и комментарии, у меня будет 2 контроллера, один для ответов и другой для комментариев. Я бы не добавил два действия в мой контроллер вопросов для несвязанного доступа к ресурсам. Есть исключения из этого, но их мало и далеко.

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


Ну, некоторые из них зависят от того, что вы подразумеваете под "контроллером". Если вы используете аннотации данных для проверки и фильтров действий для ведения журнала, это прекрасно. В контроллере нет никакой логики. Вы используете ViewModels и строго типизированные представления? Кажется, что модель, над которой работает ваш контроллер, уже должна быть упрощенной DTO, в отличие от полной сущности и создания DTO для отправки назад. Мне сложно представить ситуацию, когда контроллер отправляет электронное письмо или проверяет, что он был отправлен. Это должно быть передано на сервисный уровень. Я также смотрю на контроллер, который работает на "связанных объектах". Вероятно, это должен быть вызов одного метода в репозитории, который обрабатывает это.

Я не открыл Nerd Dinner, поэтому я не могу поклясться, что там, но может быть стоит рассмотреть?


Здесь у меня есть 5 проектов:

  • Вид
  • Контроллер, в который мы только ставим логику для методов действия, и это помощники
  • Бизнес-логика, где мы помещаем спецификацию для операций, в этом случае это были бы помощники для электронной почты, проверки бизнеса и где мы будем называть репозитории для обновления и создания объектов
  • Data Access, где мы помещаем репозитории для запросов и операций с данными.
  • ORM, где мы поместили модель базы данных и классы для обмена данными между каждым слоем

В этом случае все проекты имеют ссылку на ORM, тогда представление имеет ссылку на контроллер, контроллер на бизнес-логику и бизнес-логику на доступ к данным.

licensed under cc by-sa 3.0 with attribution.