何时使用嵌套控制器而不是angularjs中的服务?

Mig*_*sco 11 anti-patterns god-object angularjs

我刚开始使用AngularJS,所以我不是专家.

我有一个div代表我的html视图的正确区域.在那个div我有一个控制器,即

<div class="rightContainer" ng-controller="rightContainerCtrl">...</div>
Run Code Online (Sandbox Code Playgroud)

在div中我有一个表,一个搜索区域等.该div中的每个区域都有自己的控制器,它看起来像这样:

<div class="rightContainer" ng-controller="rightContainerCtrl">
...
   <div class="search" ng-controller="searchCtrl">...</div>
...
   <div class="table" ng-controller="tableCtrl">...</div>

 </div>
Run Code Online (Sandbox Code Playgroud)

例如,搜索区域有自己的控制器,它是rightContainerCtrl的子节点,因为它需要改变父节点中的某些内容(rightContainerCtrl),但是rightContainer div正在增长,现在它很大,并且包含几个嵌套控制器.

我认为使用这个嵌套控制器在这个上下文中是不好的,因为所有嵌套控制器共享父作用域,并不是所有控制器都需要访问所有父作用域变量,所有控制器都是rightContainerCtrl的"囚犯",所以它们是与其父控制器高度耦合.

它看起来像一个上帝对象反模式(在这种情况下是上帝控制器),所以我认为不是使用嵌套控制器我可以重构我的代码以消除rightContainerCtrl控制器并改为使用服务(如在外观设计模式中),然后,控制器将使用该服务,而不是共享范围变量.

但由于我不是AngularJs的专家,我不确定我是对的还是离开这个父控制器更好,也许我错过了什么,所以我的问题是

何时更好地使用嵌套控制器(嵌套范围)以及何时更好地在angularjs中使用服务?

Mar*_*cok 17

控制器/范围层次结构不应规定如何在应用程序中共享数据/模型.当您考虑Angular中的数据共享时,请考虑依赖注入.

在@ shaunhusain的答案中引用的视频中,Misko声明范围应该引用模型而不是模型 - 因此不要将数据建模/放入范围.您的模型/数据通常应该在服务中.

在编写Angular应用程序时,首先要考虑一下你的模型.使用API将它们放入服务中以获取/编辑/操作模型.然后设计你的观点.每个视图都应该投影/使用/操作模型的某个子集.为每个视图定义一个控制器,只需将所需的模型子集粘贴到视图中.使控制器尽可能薄.

(rightContainerCtrl也不建议命名控制器.控制器不应该知道演示文稿/布局.)


sha*_*ain 7

这是100%的判断调用,应该基于几点.

使用事件创建极其松散耦合的组件,他们实际上不需要彼此了解,如果你有一些情况,某些父控制器将减轻一堆控制器之间的通信需求(通过服务),那么它可能是一个更好的解.

但是,如果您对每个控制器都可以,这取决于服务(实际上不是问题),那么您可以使用该服务作为在控制器之间进行通信的手段.我已经看到很多反对单身人士的论据(其中服务是一种风味,注入单身,但是单身人士)我发现这些论点大多没有实际意义,而且通常缺乏真正优雅和简洁的解决方案.如果一个争论在关于你从A-D出发的时间怎么样,你不想走B路,但是他们似乎从来没有提供过道路CI并不真正看到这一点.

http://www.youtube.com/watch?v=ZhfUv0spHCY&t=30m34s

我无法找到视频中的确切点,但最后在这里他讨论了控制器与服务的使用(他还审查了双向数据绑定,这将阻止您需要污染全局范围,可以这么说) .