以下是我过去 6 个月在 Angular 中开发业务应用程序的看法：
控制器的角色
- 初始化（加载初始数据、设置选项）
- 通过 $scope 向模板公开变量和函数
- 应用程序流程（通过暴露可以改变状态的函数，或
$watches）
我发现，就像在传统的 MVC 框架中一样，Angular 应用程序中的控制器应该非常纤薄。几乎没有任何业务逻辑应该在控制器中，而是应该封装在您的模型中。在听了 Miško Hevery 的演讲后，我得出了这个结论：“范围的目的是参考模型而不是模型。” 这是我从那个演示中得到的最有价值和最有启发性的一句话（尽管我建议观看整个视频）；这条线直接导致我将我的控制器缩小了近 50%-70%。
例如，我的公司有一个Order. 我创建了一个模型，该模型封装了该业务对象的所有属性及其行为，并将它们注入到控制器中。我们拥有的一个业务规则是能够将Booking（另一个业务对象）添加到Order. 最初在我的控制器中，我有一个$scope.addBooking函数，它首先创建一个 new Booking，然后接受订单并执行一个$scope.order.bookings.push(newBooking). 相反，我将这个业务逻辑（addBooking函数）直接移动到我的Order模型中，然后在模板中我可以执行类似的操作，<button ng-click="order.addBooking()">Add Booking</button>而无需在控制器中添加一行代码。
当我第一次开始使用 angular 时，我在控制器中放入的很多代码，我发现可以被剥离并放置在我的模型、指令或服务中（在我的例子中主要是前两个）。留在我的控制器中的其余代码几乎都属于我上面列出的上述 3 个角色之一。它要么是初始化代码（例如，触发 AJAX 请求以获取相关业务对象的数据）、对象的范围分配，要么是处理应用程序流的函数的范围分配（例如，$scope.save或者$scope.cancel可能会将您送回不同的页面）。
控制器应该以模型为中心还是以视图为中心？
这是一个有趣的问题，我以前没有考虑过。当我听到以视图为中心时，我会想到一个控制器，它主要处理视图以及事物的显示方式。我觉得不应该有任何纯粹以视图为中心的控制器，原因是看起来以视图为中心的控制器可能可以转换为指令。您提到以视图为中心的控制器就像一个Dashboard控制器，这听起来像是绝对可以制成通用指令的东西。你的指令应该封装你的大部分视图逻辑，而你的控制器专注于简单地将你的模型暴露给视图以供使用（回到控制器的角色）。这让我认为控制器应该更频繁地以模型为中心。
我认为我能得出的唯一结论是，如果控制器开始变得过于以视图为中心（有许多主要处理视图和 UI 行为的变量和函数），那么这表明控制器的某些部分可以被拉出成一个指令，使你的控制器更苗条。