論 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做爲一個完善的自成體系的框架,從誕生到如今已經承載了太多的東西,這也致使框架最初的設計和實際發展產生了不協調,這種不協調同時又隨着開發者的需求變得更大,若是框架自己就具有了混亂的特性,對於項目而言也確實算是個不大不小的問題了.