Держать контроллер тонким (слишком много методов действия)

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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