我最近一直在考虑这个问题。到目前为止，我一直赞同John Papa的建议，可以在这里看到：
https://github.com/johnpapa/angular-styleguide#controllers
Define a controller for a view, and try not to reuse the controller for other views. Instead, move reusable logic to factories and keep the controller simple and focused on its view.
他给出了我不理解的理由，但对我来说，这主要是出于易于工作/可维护性的原因。基本上，在处理大型应用程序时，遇到一个负责几个不同视图的膨胀控制器真的很糟糕。如果开发人员想要清理控制器，他/她必须转到每个视图并确定使用的是什么以及为什么（如果它们非常相似，那么方法可以合并）这是一项很重要的工作。通常情况下（特别是如果他们受到时间限制），他们选择只是添加模型所需的任何功能，并“稍后再回来”，这就是它首先变得臃肿的原因。此外，我一直使用控制器/指令作为逻辑是否在许多视图中重复的指示（即，如果另一个开发人员走到我写的控制器他/她可以确定我只使用它与一个视图，因为否则它将是指令）。
这是一个与端点问题类似的问题，它基本上让人们根据需要添加端点，最终由于新人不了解旧端点或简单的遗忘，API变得超级膨胀和重复。
然而，正如我所说，最近我一直认为这个1-1控制器来查看关系确实对整个MVC模式起作用，因为它将模型耦合到视图并破坏了关注点的分离。我的意思是，只要一个控制器保持聚焦（即我们有一个EditUserCtrl，它的工作是编辑用户等），那么为什么两个视图不能使用该控制器呢？我的意思是，如果企业决定在另一个具有相同功能的地方需要一个新视图，为什么我不应该只编写一个新视图并将其连接到旧控制器？我想我所说的是我无法协调违反框架基础的惯例。
很想听到别人的想法。提前谢谢。
答案 0 :(得分：0)
就像你说的那样。如果一个控制器负责多个视图，任何开发人员都可以走向它，改变一些东西，希望为查看A 添加新功能，甚至不知道它正在打破查看B < / strong>即可。我认为主要目标是保持控制器干净整洁。这样，最好有2个控制器几乎完全相同，但只有2~3行代码，而文件被许多其他人无法控制的文件引用。
一方面，如果查看A 和查看B 中的某些内容发生剧烈变化，您必须更改2个控制器，但如果这是一项复杂的任务，您可能会有控制器调用某种网关，这可能意味着您根本不需要更改任何控制器（良好的结果）。 另一方面，如果你有10个不同的视图重复相同的2~3行代码，也许是抽象控制器功能的时候了。
答案 1 :(得分：0)
它并不与模型耦合，因为最佳实践是在服务中使用业务逻辑并在指令中查看逻辑，并且控制器中没有真正的逻辑。所以每个视图你可以有一个控制器，但是那个控制器应该非常瘦。就个人而言，我喜欢只使用控制器来分配和传递服务和指令之间的变量。如果你想重用控制器代码，是什么阻止你把这个逻辑放在指令和服务中？
我写的几乎没有一个控制器（我的工作是以角度编写一个大型企业应用程序）中有逻辑。有时控制器中的逻辑是不可避免的，但尽量保持尽可能少。
通过这种方式，控制器保持专注。对于大型应用程序，例如10页，对于可用性和可读性而言，每个页面都有一个小型控制器而不是一个具有混合变量的巨型控制器，并且当您想要重用方法时，它们更好和功能，把它们放在服务中。如果您发现自己有三个页面的表单或按钮具有完全相同的逻辑，那么使用自定义指令可能会更好。