Лучше иметь огромные контроллеры или многие контроллеры в MVC?

Мы создаем довольно большое приложение HR в ASP.NET MVC, и до сих пор наши контроллеры становятся довольно большими. Например, у нас есть контролер Employee, и включены все взгляды сотрудников (личная информация, вычеты сотрудников, иждивенцы и т.д.). Каждое из этих представлений может иметь несколько действий или подпрограмм (например, CRUD). Каждое действие относительно невелико, но контроллеры могут иметь десятки функций.

Есть ли какие-либо рекомендации для контроллеров разделения? Вместо того, чтобы иметь диспетчер Employee с десятками просмотров, было бы лучше иметь один контроллер для каждого подтипа (т.е. EmployeePersonalInfoController, EmployeeDeductionController, EmployeeDependentController)?

И, наконец, это даже важно?

Обновленное уточнение

Моя первоначальная проблема заключалась в действиях CRUD. Например, рассмотрим Create and Delete...

Текущие действия в EmployeeController:

  CreateEmployee()
  DeleteEmployee()
  CreateEmployeeDeduction()
  DeleteEmployeeDeduction()
  CreateDependent()
  DeleteDependent()
  etc.

Если контроллеры были разделены:

  EmployeeController
    Create()
    Delete()
  EmployeeDeductionController
    Create()
    Delete()
  EmployeeDependentController
    Create()
    Delete()
  EmployeeBenefitController
    Create()
    Delete()
  etc.

В первом сценарии наши экраны ~ 100 разбиваются на 8-10 больших контроллеров. Во втором случае у меня, вероятно, было бы ~ 50 контроллеров.

ОТВЕТЫ

Ответ 1

По моему скромному мнению, если вы держите код в своих контроллерах, это не имеет большого значения.

Большая часть вашего кода будет где-то в бизнес-слоте? Если это случай, то все, что вы действительно делаете в своем контроллере, возвращает данные в представление. Как и должно быть.

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

Вы можете посмотреть этот пост, чтобы узнать, помогает ли он. То же самое Посмотреть разные пути

Это может быть лучшим решением, чем использование подтипа, который вы предложили.

Ответ 2

Частичные классы позволяют распространять ваш класс по нескольким файлам. Таким образом, вы можете группировать соответствующие области вашего контроллера в отдельные файлы, и все же они все равно будут частью одного и того же контроллера. например.

EmployeeDeductionController.cs

public partial class EmployeeController
{
    public ActionResult Deduct()
    {
    }
    // etc
}

EmployeeBenefitController.cs

public partial class EmployeeController
{
    public ActionResult GiveBenefit()
    {
    }
    // etc
}

Ответ 3

Я бы не хотел иметь 50 контроллеров. Сейчас у меня есть 16 в моем приложении, и это нормально. Если у вас есть 50 контроллеров, у вас также будет 50 скоросшивателей для просмотров. Будет сложно найти представление и контроллер, над которым вам нужно работать. Как упоминалось выше, действия, как правило, короткие, и не так уж плохо иметь пару из них в вашем контроллере.

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

Ответ 4

Почему бы не сгруппировать их?

У вас есть структура,

employee/payroll/
    employee/payroll/giveraise
    employee/payroll/manage401k

employee/general/
    employee/general/address
    employee/general/emergencycontact

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

Ответ 5

Контроллеры предназначены для контейнеров для действий в одном контексте. И.Е. клиентский контроллер будет иметь действия, связанные с контролем клиентов. Это особенно подходит для CRUD. По этой причине я бы пошел с меньшим количеством контроллеров. Тем не менее, это действительно зависит от вас, как архитектор приложений, чтобы выбрать способ, который наилучшим образом соответствует вашему коду, и только потому, что он более распространен, чтобы сделать это одним способом, это не значит, что вам нужно.

Если у вас есть большой объем кода, я бы предложил вам посмотреть в области ASP.NET MVC. Вы можете найти отличные сообщения об этом Здесь, в блоге Скотта Гуга и Здесь в блоге Стив Сандерсон. Если у вас так много контроллеров, оно может вам пригодиться.

Просто подумал, перечитав сообщение, я подозреваю, что ваш пример не приближается к уровню сложности, который у вас есть в вашем коде. Возможно, это поможет, если вы опубликуете ситуацию, когда вы не уверены в целесообразности разделения вашего контроллера, который является более конкретным (и меньше CRUDDY, потому что CRUD довольно прямолинейный).

Ответ 6

Я бы организовал контроллеры примерно вокруг вариантов использования и их логической группировки. Например. если у вас несколько вариантов использования административных/HR-типов, которые могут быть доступны для ограниченной группы людей, свяжите их с одним контроллером. Другие контроллеры могут быть организованы вокруг определенных объектов модели домена - например, управление отпусками по самообслуживанию, запросы о зарплате и т.д. Там нет жесткого и быстрого правила, вы должны создать баланс между не возлагая слишком большую ответственность на один контроллер на повторное использование общих внутренних структур.

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

Ответ 7

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

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

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

Затем использование таких областей, как @Odd, является хорошей идеей, по крайней мере, для разделения представлений, потому что, когда у вас их много, это беспорядок.

Надеемся, что ASP.NET MVC v2 принесет нам области и инкапсулирует представления в разных сборках (на самом деле это можно сделать теперь, расширяя класс VirtualPathProvider).