论 Angular的混乱

关于angular,一直都有一种云里雾里的感觉,我想很多开发者尤其是搞过后端的程序员,对于angular中的scope controller service 都有很多特别的感触,那就是一个字 乱

关于angular的最佳实践,社区曾给出不少提议,然而我个人觉得,这些提议本身就指出了angular在一些概念上的模糊之处,JavaScript本身就是一个灵活性极大的语言,作为架构之上的框架,一点不清晰将导致很多显而易见的问题

1.scope 到底是什么 modal?state?viewModal?

　　scope这个词 字面上看是作用域,是controller下的一个对象,从这层关系看,它应该不能算modal,因为寄生于controller之上,之间是强耦合关系,然而在angular的不少示例中都直接这么写scope.name = 'jacky',于是就有了简单的绑定,迅速的显示,最初这本是彰显angular作为一个自动化框架的强大之处,然后却导致了一大批开发者将其当成了modal,或者说viewModal,在mvvm的模式中 viewmodal 是作为控制器存在的,显然单纯的scope不能负担这一重任,必须加上controller 但是controller又是一个独立的部分,那么看来 scope也不能算是viewmodal了,那么scope到底是什么?

　　我们从另一个角度看,angular除了controller service 还设计了 directive, directive 的配置中同样包含了controller scope,然而这里的scope 则绑定了directive上的属性,函数,表达式,事实上我们并没有预先设定一个scope = xxxmodal来配置指令而angular也不允许如此配置,那么从这个设计上来看scope实际上是一个ui组件的state,于是问题就来了,在一大堆看似经典的controller中scope扮演了各种角色,而隐藏背后的却实际上是个state,这就明显产生了混乱.对于scope的使用没有了一个明确定义,directive实际上也就只能在项目内部打打包了.

2.controller 到底是什么?control?viewControl?action?

　　在.net的MVC中 control是action的一个上层管理者,每一个路由不仅指定了control 同时还指定了action,这样在定义上看,同一个大页面下的不同操作被集中到一起,项目的结构也会更合理,然后来看看angular,angular对于control的定义从route设置上看更像是个action,我们可以为每一个ui组件指定control,小到一个button大到一整个页面,这导致了一个问题,那就是随着项目的推进,一大堆control估计是不能避免了,有人会说 哪还有module呢,我得说angular的module就是个命名空间,而且还不那么好使.因为JavaScript的加载机制,我们不得不为每一个文件指定一个module,这也是angular最佳实践的一部分,于是乎,有多少个control就意味着有多少个module,当然只会更多,不会更少.

　　如果说control是action,从route上看是如此,但是从view的角度来看,每一个directive都能有自己的control 显然一个directive包括各种用户交互自然不能只有一个action,从react的角度看,封装的ui组件中的control应该是一系列交互的调度者,angular中至少directive这部分也是如此设计,control是一个viewControl.

　　再从数据角度来看,社区的最佳实践给出的建议是针对每一个view都应该有独立的service作为数据抓取的部分,甚至可以说就是modal的含义了,那么control又是一个真正的control了,它负责抓取数据并且绑定到视图上,似乎看起来还不错,恩可在这之前大家都是直接在control中写http请求的吧,显然这又是一个混乱.所以control到底是啥,看心情,自己玩吧.

3.service 到底是什么?modal?工具函数?

　　在angular中service有多种定义方式有factory,provide,还有service自己,这就是个混乱了,从定义方式我们几乎可以这么来看,xxxService ->xxxfactory, xxxService -> xxxprovide, xxxService-> xxxservice, 看不懂啊完全看不懂,service定义了Service也就算了,剩下的factory和provide到底是个甚!

　　Service叫服务,从angular最初的设计来看,我觉得是作为http封装来定义的,然而随着angular的不断发展,Service变得越来越庞大和臃肿,并且混乱,因为依赖注入的特性,angular是不提倡自己来管理命名空间的,于是乎我们把各种第三方服务,工具函数,等等都封成了Service,而事实上在这些Service中还依赖着其他Service,这种定义的不明确和依赖的混乱,给项目后期带来了很大麻烦.

事实上angular作为一个完善的自成体系的框架,从诞生到现在已经承载了太多的东西,这也导致框架最初的设计和实际发展产生了不协调,这种不协调同时又随着开发者的需求变得更大,如果框架本身就具备了混乱的特性,对于项目而言也确实算是个不大不小的问题了.