什么时候在 AngularJS 中使用嵌套控制器是正确的，什么时候不正确？

Question

我是 AngularJs 的初学者，所以也许我遗漏了一些重要的东西，但我认为如果我们想在控制器之间共享信息，我们可以使用服务来代替，不是吗？

控制器不应该知道视图（html），但如果你认为，当我们使用这样的嵌套控制器时：

<div ng-controller="ControllerA">
...
   <div ng-controller="ControllerB"> 
   ...
   </div>
</div>

如果ControllerB使用ControllerA范围，那么我们只是将ControllerB与ControllerA和视图（html）耦合，因为这里的html决定了控制器中范围的层次结构，如果我们想改变所有的html比如一个新的设计，html结构改变如下：

<div ng-controller="ControllerA">
...
</div>

<div ng-controller="ControllerB">
...
</div>

然后视图中的这种变化也会影响我们的 ControllerB 逻辑（因为它使用 ControllerA 范围），所以对我来说，AngularJS 中的嵌套控制器看起来像一个反模式，但也许我遗漏了一些东西，所以..

什么时候在 AngularJs 中使用嵌套控制器是正确的，什么时候不正确？

你能给我一些用例吗？

谢谢

Answer 1

在您的示例中，控制器层次结构是 HTML 布局的副作用，这是真的。

但是，我可以想到两次它是函数所固有的。一个是例如 ng-repeat 指令。子范围从父范围继承，这是正确的，因为您希望父范围将子范围作为一个集合来控制。

第二个是逻辑单元。换句话说，如果我正在为产品构建一组页面，我可能会创建一个父产品控制器，然后创建用于选择产品、添加产品、删除产品的子控制器。这是一种独立于视图实现的逻辑关系。然而，这样做是有道理的，因为现在我可以通过多种方式设置我的 UI 而不会产生副作用。例如，也许我默认使用带有列表的网格视图，然后使用路由转换到详细信息视图 - 这将起作用。或者我可能决定将选择放在同一页面的左侧，将详细信息放在右侧——同样的事情会起作用。我可以测试和协调这些控制器，但是虽然我有一个逻辑继承，但它不会对 UI 的实现方式施加层次结构。

如果我有不相关的控制器，但有一个共同的“全局关注点”或我们称之为“方面”，那么我将使用服务，而不是担心控制器层次结构，而是处理与该服务的交互。