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