Контроллеры бога - Как предотвратить их?

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

Я чувствую это чувство, потому что вы упоминаете о возможности увеличения зависимости вашего контроллера от огромных зависимостей. Что ж, если FavouritesController должен знать о питании и избранных упражнениях (для отображения в одном представлении), не делайте ваш контроллер зависимым от двух репозиториев, таких как классы. Вместо этого инкапсулируйте это координационное поведение. Возможно, создайте службу FavoritesService, которая знает, как возвращать избранное как по питанию, так и по упражнениям. Эта служба может делегировать NutritionFavoritesService и ExerciseFavoritesService. Так ты

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

Я также испытал такого рода головные боли при обслуживании и считаю, что использование метода, подобного «Rails», очень помогает в поддержании сосредоточенности моих контроллеров и их разгруженности.

Если я обнаружу, что добавляю действия с необычными названиями Например. Чтобы использовать пример ведения блога, AddPostToBlog, это будет флаг для создания нового контроллера Post с действием Create.

Другими словами, если действие не является одним из действий «Индекс», «Создать», «Создать», «Показать», «Изменить», «Обновить» и «Уничтожить», я добавляю новый контроллер, специфичный для требуемого мне действия.

Для вашего примера.

SearchController {
    SearchExercise
    SearchNutrition
    //... etc
}

Я бы реорганизовал это, чтобы ...

   SearchExerciseController {
           Index   
   }

   SearchNutritionController {
           Index   
   }

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

Например. Возвращает ли действие SearchExercise представление для поиска упражнения или действительно выполняет поиск? Вероятно, вы могли бы убедиться в этом, посмотрев на параметры и тело, но это не так просто, как, например, пара действий «Создать» и «Создать» или «Изменить и обновить».

SearchController {
    SearchExercise       
}