请原谅我，如果这听起来很愚蠢，但我已经使用 AngularJS 一段时间了，到处都看到人们告诉我将我的逻辑包装在指令(或服务？)而不是我的 Controller 中并只保留我的 Controller 中的绑定(bind)。除了指令的可重用性方面之外，还有其他原因吗？
直到现在我还没有真正理解为什么会出现这种情况。编写指令不会带来很多开销吗？我在 Controller 中编写逻辑时没有遇到任何问题，这很简单。 这种方法有哪些缺点？
最佳答案
Controller 是执行与范围相关的所有操作的正确位置。这是你写所有内容的地方
$scope.$watch(...)
并定义您需要从 View 访问的所有$scope函数(例如事件处理程序)。一般来说，事件处理程序是一个计划函数，它将依次调用函数服务。
$scope.onLoginButtonClick = function(){
AuthenticationService.login($scope.username,
$scope.password);
};
在极少数情况下，您可以在其中添加 promise 成功处理程序。
不要:在 Controller 中编写业务逻辑
前面的示例之所以如此，有一个非常具体的原因。它向您展示了一个 $scope 函数，该函数依次调用服务中的函数。 Controller 不负责登录机制或登录如何发生。如果您在服务中编写此代码，则将服务与 Controller 解耦，这意味着您想要在其他任何地方使用相同的服务，您所需要做的就是注入(inject)并触发该函数。
future Controller 的规则:
- Controller 应保持零逻辑 Controller 应该仅绑定(bind)对模型的引用(并调用从 Promise 返回的方法)
- Controller 仅将逻辑组合在一起
- Controller 驱动模型更改和 View 更改。关键词;驱动，而不是创建/持久，它触发它们!
- 委托(delegate)更新工厂内部的逻辑，不解析 Controller 内部的数据，仅使用更新的工厂逻辑更新 Controller 的值，这避免了跨 Controller 的重复代码，并使工厂测试变得更加容易
- 让事情变得简单，我更喜欢 XXXXCtrl 和 XXXXFactory，我确切地知道两者的作用，我们不需要花哨的名称
- 在共享方法中保持方法/属性名称一致，例如 this.something = MyFactory.something;否则会变得困惑
- 工厂保存模型，更改、获取、更新和保留模型更改
- 将工厂视为需要持久化的对象，而不是持久化在 Controller 内
- 与工厂内的其他工厂交谈，让他们远离 Controller (例如成功/错误处理)
- 尽量避免将 $scope 注入(inject)到 Controller 中，通常有更好的方法来完成您需要的操作，例如避免 $scope.$watch()
关于AngularJS:为什么不在 Controller 中编写逻辑？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31454488/