Хранение контроллера тонким (слишком много методов действий)

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

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

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

Нужно ли рефакторировать контроллер с большим количеством тонких действий? Если да, то каков наилучший способ сделать это?

Ответ 1

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

Что касается наличия "слишком много" методов действий, это решение. Это действительно может быть признаком хорошей организации, что у вас есть все акценты на одном. Кроме того, возможно, вы используете действия специально для использования с RenderAction? И это может быть просто характер вашего решения, что есть много вещей, связанных с вашей темой Controller.

Итак, я предполагаю, что ты, наверное, в порядке. Однако, чтобы убедиться, что на бумаге для заметок выведите контроллер на 2 или 3 контроллера и нарисуйте, как ваши истории будут работать от действия к действию. И если вы обнаружите, что ваш рабочий процесс работает с большим количеством контроллеров, вы должны его разбить. Особенно, если вы собираетесь добавить эту функцию позже. Чем скорее вы это сделаете, тем лучше.

Ответ 2

Хороший вопрос.

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

Ответ 3

Другим структурным вариантом, который у вас есть, является введение частичных классов для логических группировок действий. И используя что-то вроде vscommands для группировки файлов.

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