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

时间:2013-07-22 17:48:18

标签: angularjs anti-patterns god-object

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

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

<div class="rightContainer" ng-controller="rightContainerCtrl">...</div>

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

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

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

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

它看起来像God object反模式(在这种情况下为上帝控制器),所以我认为不是使用嵌套控制器,我可以重构我的代码以消除rightContainerCtrl控制器并改为使用服务(如a facade design pattern),控制器将使用该服务,而不是共享范围变量。

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

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

2 个答案:

答案 0 :(得分:17)

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

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

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

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

答案 1 :(得分:7)

这是100%的判断,并且应该基于几点。

使用事件会创建极其松散耦合的组件,如果您遇到一些父控制器可以减轻在一组控制器之间进行通信的需求(通过服务),那么它们实际上并不需要彼此了解,那么它就是可能是一个更好的解决方案。

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

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

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