上帝控制者 - 如何预防他们?

Mun*_*PhD 15 model-view-controller asp.net-mvc design-patterns god-object

在我一直在研究的一些MVC项目中,显而易见的是,有一些有问题的控制器已经有机地成长为上帝类 - 如果你愿意的话,每个人都在他们自己的领域.

这个问题可能更多的是"什么在哪里",但我认为这是一个关于SRP(单一责任原则),DRY(不要重复自己),保持简洁,"敏捷"的重要问题 - 而且我没有足够的经验(有这种模式和一般设计)对此有所了解.

在一个项目中,我们有一个NutritionController.随着时间的推移,它已经成长为包含这些动作(许多动作都有各自的GET,POST和DELETE方法):

Index (home controller)
ViewFoodItem
AddFoodItem
EditFoodItem
DeleteFoodItem
ViewNutritionSummary
SearchFoodItem
AddToFavorites
RemoveFromFavorites
ViewFavorites
Run Code Online (Sandbox Code Playgroud)

然后我们有一个ExerciseController,它将包含许多类似的操作,例如搜索和收藏夹操作.这些应该重构到他们自己的控制器中,以便它是这样的吗?

SearchController {
    SearchExercise
    SearchNutrition
    //... etc
}

FavoritesController {
    ViewNutritionFavorites
    AddToNutritionFavorites
    AddToExerciseFavorites
    EditNutritionFavorites
    EditExerciseFavorites
    //... etc
}
Run Code Online (Sandbox Code Playgroud)

在我看来,如果你将它们分解为单独的控制器,你将在某种程度上增加一个令人难以置信的大依赖性来处理你需要的信息.或者你将拥有一个非常难以处理的完全通用的处理应用程序,因为你必须跳过这么多的箍来获得你想要的效果(在M,V或C级别).

我想错了吗?例如,我应该有一个通用的收藏夹对象,然后让控制器决定将它扔到哪个视图?

*很抱歉拼写出缩略语 - 我这样做是为了防止其他人遇到这个问题并且对这些东西是什么一无所知

编辑: 我执行的所有逻辑几乎都在服务层中处理.例如,控制器将'new'FoodItem发送给服务.如果它已经存在,或者它有错误,服务会将其冒泡回控制器.

Sov*_*iut 12

我会根据责任打破你的第一个清单:

HomeController的

  • 指数

FoodItemController

  • ViewFoodItem
  • AddFoodItem
  • EditFoodItem
  • DeleteFoodItem
  • SearchFoodItem

NutritionController

  • ViewNutritionSummary

FavoritesController

  • 添加到收藏夹
  • 从收藏夹中删除
  • ViewFavorites
  • SearchFavorites

Django的MVC方法是将职责分离为"应用程序",每个应用程序都有自己的模型,控制器,甚至模板(如有必要).你很可能有一个Food应用程序,一个营养应用程序,一个搜索应用程序和一个收藏夹应用程序.

编辑:OP提到搜索更具体到每个控制器,所以我做了那些动作.但是,搜索也可能只是一个普遍的全局事物,因此在这些情况下,SearchController会很好.