作为后端开发人员，我对 Angular UI MVC 概念有点挣扎。
我试图与我的后端MVC绘制相似之处，这样我就能更好地理解Angular背后的心态。
在我的后端，我有服务与存储库（或DAO（ D ata A ccess O 对象）交谈，我们过去如何调用它们），控制器调用服务来完成工作（因为他们只传输数据而不是繁重的工作）并与客户端（即浏览器）交谈，我的模型是一个组合（DTO（ D ata < strong> T ransfer O 对象）和ORM中的实体）。
因为我本来就受到后端的启发而只返回/接受JSON（对于JSP，FreeMarker，Velocity以及其他所有使我的测试生活如此艰难的其他人而言）。我会说在我的后端我只有模型控制器。从后端的角度来看，我的 View 是AngularJS作为JSON数据我返回可以标记为我的 Model 的一部分，但绝对不是我的 View 。
现在，当我开始考虑AngularJS的UI MVC 我不明白谁应该使用$ http服务与后端交谈。分散在网络上的无数例子对我没有帮助。它们要么太简约，要么在完整的上下文中不显示$ http的用法（只需从控制器调用）。
我可以轻易地为两者争辩。
案例A：如果AngularJS将后端视为 Model ，则角度服务的责任是调用$ http与后端进行通信以检索/发布数据。在这里，角度控制器仍然充当 View 和 Model 之间的基本传输。偶尔调用服务来从后端获取和处理数据。
案例B 我还可以说，坚持 - ＆＃34; no＆＃34;，如果角度控制器的角色仅用于传输，那么他们应该从后端获取数据并传递到所需的目的地，即角度的服务/视图（如果不需要进一步处理）。
那是哪一个＆＃34;对＆＃34;？或者至少被UI / fullstack开发者广泛接受？
答案 0 :(得分：2)
控制器应该只使用视图以尽可能最小的方式连接数据和逻辑。一个庞大的控制器建议要么需要划分视图，要么将逻辑抽象为服务。 $http次呼叫绝对属于服务。控制器并不关心数据是如何来的，只是它来了。所以：
// controller doesn't care how
getData().then(function(data) {
VS
// controller is too concerned with "how"
$http.get('/the/path').then(function(data) {
通常在示例代码中看到控制器中的$http调用，但不会在专业生产代码中看到。
答案 1 :(得分：2)
我强烈建议案例A：在服务中使用它。
将Angular控制器视为拥有它们所分配的每个特定视图，并为这些控制器提供现成功能。
另请注意，单个页面可以包含许多视图，每个视图都可以绑定到其自己的给定控制器实例。因此，基于$http的函数等被多次实例化并没有多大意义。对于服务，它将被实例化一次，然后在注入它的任何控制器之间共享。这也是在控制器之间共享数据的好方法，也是将服务用于任何给定任务的最重要原因之一。
答案 2 :(得分：0)
另一个建议是将Angular视为MVC会导致问题。 Angular足够灵活，可以遵循多种设计模式，因此MVW（Model View Whatever）名称，但我见过的大多数应用程序都倾向于遵循MVVM模式。出于这个原因，我会说控制器在大多数情况下都不应该知道$ http。