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

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

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

и, наконец, имеет ли это вообще значение?

Обновлены Разъяснения

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

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

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

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

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

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

7 61
asp.net-mvc architecture model-view-controller

7 ответов:

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

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

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

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

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

12

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

EmployeeDeductionController.cs

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

EmployeeBenefitController.cs

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

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

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

10

почему бы не объединить их?

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

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

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

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

3

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

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

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

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

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

2

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

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

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

1

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

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

1