在此开始角度开发者。
让我首先说，我真的很欣赏angular，我认为它是一个架构非常好的框架。
也就是说，我不明白为什么存在控制器。让我自己解释一下：
据我所知，服务具有明确的角色：1） 在整个应用程序中存储所需的模型部分2） 执行业务逻辑3） 与服务器通话
视图：1） 显示型号
指令：1） 创建作用域2） 向他们创建的作用域公开功能，通过这些作用域从用户那里获取输入a） 更改模型b） 操作DOM
控制器的作用是什么？指令似乎是为执行控制器所做的所有工作而设计的
在指令操作DOM时，控制器是否应该操作模型？
Angular并不是一个特别固执己见的框架，尽管有些人可能会告诉你它是。
控制器是一种访问/创建范围并将许多其他部分链接在一起的简单方法。它们灵活、简单，非常适合"你只需要在这个地方做一些事情"
指令应该是可重用的和可表达的，比如"给我一个按钮来发出ajax请求的东西"，您需要在5个地方这样做。控制器对该任务没有意义。
每当你真正需要一个控制器时，使用指令是非常重要的，而且可能有点难看，这就是我认为差异化的意义所在。
话虽如此，如果你认为指令更好，没有什么能真正阻止你在任何地方使用指令。
让我们引用AngularJS文档：
来自本章：
什么是指令
在高层，指令是DOM元素上的标记（如属性、元素名称、注释或CSS类），告诉AngularJS的HTML编译器（$compile）将指定的行为附加到该DOM元素，甚至转换DOM元素及其子元素。
来自那一章：
使用控制器：
设置$scope对象的初始状态。
将行为添加到$scope对象。
不要使用控制器：
操纵DOM——控制器应该只包含业务逻辑。将任何表示逻辑放入控制器会显著影响其可测试性。Angular在大多数情况下都有数据绑定，指令封装手动DOM操作
格式输入--改为使用角度形式控件。
滤波器输出——改为使用角度滤波器。
在控制器之间共享代码或状态--请改用角度服务。
管理其他组件的生命周期（例如，创建服务实例）。
你几乎什么都有了。
微妙的一点是，由于AngularJS仅在Html页面和js代码之上工作（而不是更传统的客户端/服务器设置），因此服务器通常支持的视图和"后端"都嵌入在同一文档中，而指令作为操作DOM的工具，也是引导应用程序，因此，直接在那里对应用程序进行硬编码一定很诱人。这就是框架中已经发生的事情：特定的指令专门用于控制器。
在MVC体系结构中，控制器帮助桥接视图和模型，并集中围绕一组模型及其数据的功能。它还有助于从业务逻辑中划分什么属于纯UI：除非您计划提供新功能，否则更改UI不应影响该逻辑。但同样，由于平台的限制，这些模式在这里重叠。
决定性的参数可能如下：如果你没有使用内置的控制器模块和指令，你将不得不派生新的指令来将UI入口点绑定到业务逻辑，在这个过程中，你将按照控制器模式重新创建对象，以在这些入口点后面保存代码。
AngularJS让你变得简单，并让你开箱即用。
或者你可能会想出一个替代方案？