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

Я бы разбил ваш первый список в зависимости от ответственности:

Контроллер дома

• Индекс

Контроллер продуктов питания

• ViewFoodItem
• AddFoodItem
• EditFoodItem
• DeleteFoodItem
• ПоискЕдаЭлемент

Контроллер питания

• ViewNutritionСводка

Контроллер избранного

• Добавить в избранное
• Удалить из Избранного
• ПосмотретьИзбранное
• ПоискИзбранное

Подход Django к MVC заключается в разделении обязанностей на "приложения", каждое со своими моделями, контроллерами и даже шаблоны при необходимости. Скорее всего, у вас будет приложение «Еда», приложение «Питание», приложение «Поиск» и приложение «Избранное».

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

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

У меня такое чувство, потому что вы упомянули о возможности роста огромных зависимостей вашего контроллера. Что ж, если FavoritesController должен знать о питании и избранных упражнениях (для отображения в одном и том же представлении), не делайте ваш контроллер зависимым от двух репозиториев, таких как классы. Вместо этого инкапсулируйте это координационное поведение. Может быть, создать службу FavoritesService, которая знает, как возвращать избранное как по питанию, так и по упражнениям. Эта служба может делегировать функции NutritionFavoritesService и ExerciseFavoritesService. Таким образом, ваш контроллер заканчивается только с 1 зависимостью, вы держите вещи СУХИМИ, применяете SRP и концентрируете свою бизнес-логику в каком-то другом месте, кроме контроллера.

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

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

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

Другими словами, если действие не является ни одним из действий Index, New, Create, Show, Edit, Update и Destroy, я добавляю новый контроллер, специфичный для требуемого действия.

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

SearchController {
    SearchExercise
    SearchNutrition
    //... etc
}

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

   SearchExerciseController {
           Index   
   }

   SearchNutritionController {
           Index   
   }

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

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

SearchController {
    SearchExercise       
}