论 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做为一个完善的自成体系的框架,从诞生到如今已经承载了太多的东西,这也致使框架最初的设计和实际发展产生了不协调,这种不协调同时又随着开发者的需求变得更大,若是框架自己就具有了混乱的特性,对于项目而言也确实算是个不大不小的问题了.