AngularJS - 下一個大框架
AngularJS
AngularJS是web應用的下一個巨頭。
AngularJS如果為創建web應用而設計,那它就是HTML的套路了。具有數據綁定, MVW, MVVM, MVC, 依賴注入的聲明式模板和出色的可測試性都是用純客戶端 JavaScript來實現的! AngularJS 是一個創建富客戶端應用的JavaScript MVC框架,它組織良好,經過嚴格測試,多功能,強大并且十分靈活。你仍然需要具有服務端后臺,但大多數的用戶交互邏輯將優雅地放到客戶端上處理。
AngularJS是一個開源的web應用框架,由Google和社區進行維護,它可以創建單頁的應用程序,一個頁面的應用僅僅需要HTML,CSS和JavaScript在客戶端。它的目標是增強頁面的模型-視圖-控制(MVC)的功能,為簡化開發和測試。
它是一個建立在厚客戶端的清爽的新模塊web應用程序。一個健壯的框架建立在商業應用網絡上。它鼓勵最佳實踐,開發模型和開發高質量的可維護的模塊化應用程序。它的團隊是世界一流的,社區是極其出色的,它結合最棒的功能來創建web應用。
AngularJS 允許你編寫客戶端的web應用程序,如果你有一個智能瀏覽器。它允許你使用好用的舊式的HTML作為你的模板語言,允許你擴展HTML語法來清晰、簡潔的 表達你的應用組件。它通過雙向數據綁定使你的UI(視圖層)與你的JavaScript對象(模型層)的數據自動同步。幫助你更好的構建你的應用和更方便 的測試,AngularJs告訴瀏覽器如何依賴注入和控制反轉。它幫助改良了允許異步回調和延遲、使客戶端導航和深層鏈接使用哈希bang格式地址和 HTML5 pushStat與服務端通信更容易。
Angular 提供了:
-
結構模型的引入(MVC,SPA等)
-
增強HTML支持新特性。
-
避免直接DOM操作來避免很難調試不可追蹤的代碼。
-
包含低耦合和高可復用性
-
應用程序內部規則測試
-
視圖模板更接近服務器端模板
AngularJS 是基于聲明式編程模式 是用戶可以基于業務邏輯進行開發. 該框架基于HTML的內容填充并做了雙向數據綁定從而完成了自動數據同步機制. 最后, AngularJS 強化的DOM操作增強了可測試性.
設計初衷:
-
將DOM操作從應用中解耦. 增強了可測試性。
-
應用測試性與開發代碼同樣重要. 測試的復雜程度與代碼的設計結構強相關.
-
客戶端與服務端解耦. 實現了并發處理機制增強了代碼復用性.
-
在開發全過程中作出指引: 從UI到業務邏輯最終到測試環節.
架構
AngularJS的關鍵特性
可測試性,依賴注入,邏輯/視圖層的分離,還有設計者和開發者之間的協調合作是一個開發者對一個框架最期待的幾樣東西。Angular絕對滿足上述要求。在JS領域,Angular能適配這寫令人耳目一新的要求看起來是多么驚人。
雙向數據綁定:
數據綁定可能是AngularJS里最酷,最實用的功能。 它將節省你大量的樣板代碼編寫。 一個典型的Web應用程序可以包含多達80%的代碼基礎,如遍歷,操作,并聽取了監聽DOM。 數據綁定使得不用編寫這些代碼,這樣你就可以專注于你的應用程序。
考慮下你的應用程序的模型為單源信任的。 你的模型就是你去讀取或更新應用程序中的任何東西的地方。這種投射是無縫的,不需費你一兵一卒。AngularJS雙向數據綁定會處理DOM和模型之間的同步,反之亦然。

模板
在AngularJS, 模板就是原生的HTML. 做了基于視圖的增強. 這樣做最大的好處在于拉近了開發與設計人員的工作流. 設計人員操作HTML完成設計,開發直接在HTML上作相應的功能開發.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
MVC
AngularJS引入了軟件設計的MVC模式.這對于使用者來說仁者見仁智者見智. AngularJS并不是完全的MVC而是 MVVM (Model-View-ViewModel).
-
模型
model就是數據模型 就是一些JavaScript 對象. 沒必要從父類繼承,代理包裝亦或是使用getter/setter來使用. 使用vanilla JavaScript 十分方便便捷.
-
視圖
視圖就是提供特殊數據或方法來支持特定場景的對象.
視圖對象就是 $scope. $scope就是個簡單的js對象,提供一些簡單的API監控其狀態.
-
業務控制
控制器起到設置 $scope對象的初始狀態及后續的動作關聯。
-
頁面
在.AngularJS處理完相關的業務邏輯進行HTML模式的展示。
這樣就奠定了應用的架構. $scope對象擁有數據的引用關系, 控制器定義行為, 視圖處理頁面展示布局以及相應的處理跳轉.
依賴注入
AngularJS 提供了依賴注入的子系統幫助開發人員降低開發復雜度,提高測試效率.依賴注入將業務代碼與配置實現解耦,提高了代碼的可測性.
有了DI無需每次都創建指定的對象依賴關系,而后面配置. 這樣就能按需分配而無需自己制定或是查找. 就像要說一句"Hey I need X', DI就會幫你創建并發送給你.
采用依賴注入后能體驗到的好處主要包括:
-
代碼更易于維護。
-
API更為簡練和抽象。
-
代碼更易于測試。
-
代碼更加模塊化、可復用性更強。
指令
指令可以被用來創建自定義的HTML標簽,這些標簽可以用作新的自定義的控件。它們也可以用來"渲染"有一定行為的元素,也可以以一些有趣的方式來 操作DOM屬性。一個指令就是一個能引入新語法的東西。把分離的組件組合成一個組件,這種創建應用的方式將使得添加、修改和刪除頁面功能變得異常簡單。指 令是AngularJS的一個非常強大且獨有的特性。
從更高的層次說, DOM 元素上的指令 (像是屬性,元素名,注釋或是 CSS ) 等給 AngularJS's HTML 編譯器傳遞的數據($compile) 從而傳遞指定的功能到DOM元素或是子元素。
Angular 有很多這樣的內置指令,像是 ngBind, ngModel, 和ngView.Y還能自定義指令,當Angular啟動后HTML編譯器就會自動建立DOM元素的指令映射.
測試
AngularJS 意識到凡是js寫的代碼需要加強測試. 這在 AngularJS 設計之初就有了, 于是Angular的可測試性不言而喻.
JS是解釋性的動態語言,設計相應的測試決不可小覷.
AngularJS 完全基于可測的根基設計出來的. 它提供了端到端的單元測試. API文檔就是詳細的測試覆蓋說明.
AngularJS Bootstrap Process
學習曲線
剛開始學Augular覺得開發應用需要有相當的編程基礎. 不得不說這確實是一款了不起的開發框架,它要求開發人員設計低耦合和可維護的應用. 使用AngularJS 的復雜度就像使用PHP,Ruby on Rails等等, 都需要處理依賴注入,路由,值域等等. 這也不是什么新技術了. Angular只是發揚光大了.
JS MVC frameworks
MVC (模型-視圖-控制器) 是一套設計模式,可以分層設計應用. 將數據(模型) 與用戶視圖 (視圖)解耦, 通過中間控制器 (Controllers) 處理業務邏輯, 用戶輸入以及相應的邏輯跳轉. 現代JS框架提供了簡易的操作以及SoC (業務分離) 更好的實現了MVC .
MVC 對于JS有很多好處— 提高了高可靠性的代碼. 已被很多語言大量測試驗證過,具有高可靠性.
MVC 實現的三層結構:
-
模型: 是應用程序中用于處理應用程序數據邏輯的部分。
通常模型對象負責在數據庫中存取數據. -
視圖: 是應用程序中處理數據顯示的部分。
通常視圖是依據模型數據創建的. -
控制: 是應用程序中處理用戶交互的部分。
通常控制器負責從視圖讀取數據,控制用戶輸入,并向模型發送數據.
JavaScript ‘MVC’可以幫助構建我們的代碼,但盡信書不如無書. 有些框架把控制器放在視圖模式(比如 Backbone.js) 有些框架全部混在一起使用. 除此外還有其他的MVC模式,像是 MVP (Model-View-Presenter) and MVVM (Model-View ViewModel). 即便是MVC設計模型, 不同的語言也有不同的實現方式. 像是, 有些MVC實現會有自己的視圖變更控制器亦或是控制器視圖. 這些框架被稱為 MV* 框架, 意味著你會有模型,視圖但更會有其他的部分.
很長一段時間 AngularJS 是很標準的 MVC (或者說在客戶端實現這一塊),但在后來一段時間內隨著代碼重構和API的重寫,現在更是 MVVM模式了 – $scope 對象被認為是視圖模型然后被稱為控制器的功能模塊包裝. 這樣分配到MV模式中是有些好處的.它會幫助開發者使用簡易的API開發基于框架的代碼. 也能統一開發的共識。 使用MVC的初衷就是分解結構, 然后通過設置參數決定具體使用哪種 MV* 框架, Igor Minar (核心 AngularJS團隊)宣稱AngularJS 是 MVW 框架- Model-View-Whatever. whatever就是定制化的需求.
為什么使用 JS MVC 框架
再來看看使用MVC和傳統開發模式的區別
傳統Web應用
傳統模式處理業務請求全部放在服務端,前段只是頁面交互 (瘦客戶端, 胖服務端). 這會有以下問題:
-
分布式處理能力弱 – 服務器處理大量業務,性能堪憂.
-
相應壓力 – 傳統應用的響應速度是個硬傷.
-
開發復雜度 –C/S結構的應用開發是比較復雜的. 由于每次請求響應都涉及到交互設計,很容易出錯。未解決該問題的框架也是層出不窮,可惜易用性有待考究.
-
被攻擊危險 – 混編業務代碼和交互代碼,增加了代碼受攻擊的概率.在復雜度很高的應用中更是不容易控制安全性。
-
服務端的負載過大 – 所有客戶端的請求都需要經由服務端處理,這意味著所有的session都要等待30分鐘后才能被釋放,這時客戶請求早已處理完畢,但還在占用系統資源,大大降低了系統性能和伸縮性.
-
離線處理 – 擁有離線處理能力是web應用的競爭力,尤其在處理大量客戶端請求的應用中,離線處理部分業務更是不可或缺.
-
互操作性弱– 由于混雜編寫,代碼邏輯很難分割,擴展功能變得復雜.
JSMVC Web 應用程序
JS MVC web應用程序架構主要致力于將服務端的邏輯處理轉移到客戶端和實現瘦客戶端web應用程序。client/server模型的處理邏輯和代碼被委托給瀏覽器的好處是:
-
可擴展性:很容易看到利用客戶端處理在可擴展性方面的優勢。服務器處理能力保持不變的前提下,應用被越多的客戶使用,那么越多的客戶端機器可以被使用(直到你購買更多的服務器)。
-
實時的用戶響應:客戶端代碼可以立即對用戶的輸入作出反應,而不需要等待網絡傳輸。
-
結構清晰的編程模型:用 戶界面可以有效地分離應用程序的業務邏輯。這樣的模型為安全提供了一個更加簡潔方法。所有通過用戶界面的發出的請求,我們可以在數據通過各種接口前進行安 全檢查。使用復雜的分析流程會讓安全分析變得更加復雜。另一方面,用清晰的web服務接口,有明確的網關安全工作和安全分析更簡單直觀,漏洞可以快速發現 并糾正。
-
客戶端狀態管理:在客戶端維護臨時會話狀態信息可以減少服務器上的內存負載。這也允許客戶利用更多的RESTful交互,可以進一步提高可伸縮性和使用緩存的時機。
-
離線應用-如果大部分應用程序的代碼已經在客戶端上運行,那么創建一個離線版本的應用程序可以肯定將會變得更加容易。
-
互操作性:通過使用結構化數據和最小限度的api進行交互,這樣更容易連接額外的消費者和生產者與現有系統進行交互。
為了開發實現一個客戶端web應用程序,需要組織我們的 項目結構,這樣更易于后期的管理和維護。一個應用程序的腳本超過幾十行的時候,如果它的組件之間的功能沒有分開處理,這樣應用會變得越來越難管理。我們一 開始開發一個web應用程序的時候,可能會覺得簡單地通過一個DOM操作庫(如jQuery)和一些實用的插件就可以完成了。這樣我們很容易就被應用里面 jQuery的嵌套回調函數和沒有任何組織結構的DOM元素給搞蒙了。為了避免前面說到的問題,我們采用spaghetti code (一個描敘代碼的術語,用來形容代碼難以閱讀和因為缺乏組織結構難以維護)。像使用jQuery這樣的DOM操作庫和一些其他的實用庫我們可以更加容易使構建一個網頁。但是,這些庫在我們構建web應用程序時失去作用。
web應用程序不像一個普通的網頁,他們更傾向于與用戶的交互并且需要實時與后端服務器通信。如果你沒有使用MVC框架來處理,這樣會最終會讓你寫出一些編寫混亂、非結構化、不可維護、不可測試的代碼。為了避免“spaghetti”式的代碼,那么JavaScript開發人員必須首先要了解這種模式提供了什么東西。這就可以看到這些框架能夠讓我們做什么哪些不同的事情。
使用JavaScript構建一個單頁面應用程序的時候,不管是否擁有一個復雜的用戶界面或者只是為了減少HTTP請求的數量,你可能會發現自己寫的很多可以組成一個MV *框架的代碼。剛開始的時候,使用自己想出來的方式來避免“spaghetti”式代碼寫一個應用框架并不是一件很難的事情,但是寫出像Angular/Backbone這樣的代碼水平那就不太可能了。
我們會發現有更多的人會傾向于構建一個應用,而不是試著 去將DOM操作庫、模板、路由結合到一起。成熟的MV *框架通常不僅包括很多你發現自己寫過的類似的功能代碼,而且也包含了很多你曾經遇到并且已經解決了的問題。框架為你節省了很多時間,這就是框架不能低估 的價值所在。
現在的瀏覽器提供了豐富的功能,變得越來越強大,這不僅讓在JavaScript中構建成熟的web應用程序成為可能,而且這個方式越來越受歡迎。根據 HTTP Archive數據顯示,今年部署的JavaScript代碼規模增長了45%。
隨著JavaScript的人氣攀升, 我們的客戶端應用程序比以前復雜得多 。一個應用程序開發需要多個開發人員合作,所以編寫可維護和可重用代碼在新的web應用程序時代是非常重要的。設計模式對于編寫可維護和可重用的代碼是很重要的。 在過去幾年時間里面,有很多JavaScript MVC框架已經被設計開發出來了,比如AngularJS,backbone.js, ember.js,還有很多其他的框架。雖然他們都有其獨特的優勢,但是每一框架都會鼓勵開發人員遵循一定的形式以編寫出更加結構化的 JavaScript代碼。
什么時候需要使用一個JS MV*框架
如果你在構建一個應用,它的客戶端有許多重量級的功能,用純JavaScript很難應付,那你就應該考慮使用一個MVC框架。 如果選擇錯誤,你將會錯過MVC框架提供的功能,陷入重新發明輪子的境地。
要注意的是,如果你構建的應用在服務器端有很多重量級功能(即視圖生成/展現邏輯)并且在客戶端沒有多少交互的話,這時你會發現使用MVC框架就像是殺雞用牛刀。在那種情況下更好的選擇是,使用一個更簡單的、有少量附加功能的DOM操控類庫。
下面這個列表并不完備,但是我們希望它能提供充分的理由幫你決定是否在你的應用中應該使用一個MVC框架:
-
你的應用需要異步連接到后臺
-
你的應用有這樣的功能,它不需要重新載入整個頁面(比如給博文增加一條評論,無下限滾動)
-
多數視圖或者數據操作將會在瀏覽器內完成,而不是在服務器端完成
-
同樣的數據在頁面上需要進行不同方式的渲染
-
你的應用有許多瑣碎的交互來修改數據(按鈕, 開關)
滿足這些情況的比較好的web應用的例子有Google Docs,Gmail或者Spotify。
客戶機/服務器架構的web應用程序
世界已經被改變,部分應用的邏輯已經被移到客戶端。當我們需要以某種方式處理來自服務器的所有數據時,這里就描述這種情形。JS MVC框架鼓勵把表現層邏輯從服務器端移動到客戶端,實現了RIA(Rich-Internet-Apllication),傳統web應用程序下的客戶 機/服務器架構和JS MVC下的客戶機/服務器架構都基于web應用。

客戶端一側的MVC可以處理整個MVC棧。如果你同時使用服務器和客戶端MVC,那么你會復制你的模型和路徑。客戶端一側的MVC基本上允許你將你 的服務器和客戶端連接起來。為什么你的服務器要發送視圖層?為什么不發送以json為格式的模型并加載它到客戶端一側,讓客戶端去渲染視圖。你甚至可以在 將來為其規定路由。為什么服務器要處理路由?客戶端可以做這個。僅僅允許客戶端去訪問你的RESTful數據庫就行,并且你不需要任何服務器端的MVC。
較流行的一種包含客戶端服務端的模式是 后端RESTful API 通過 JSON發送數據模型 客戶端使用MVC模式 處理應用.
Client-side MVC with server-side RESTful API
Data Flow
AngularJS和其他JS MVC框架的對比
在與其他JS MVC框架的爭戰中,AngularJS已經勝利了。它已經證明了自己是所有JS MVC框架中最成熟的。下面是來論證的數據
社區支持
(數據來自Github.com)
(數據來自StackOverflow.com)
隨著時間推移,興趣的趨勢
(2011年8月-2014年6月)
(上一年)
使用統計
特性對比
用戶入門
工作趨勢
對比Angularjs和類似Dojo的企業級工具集(Toolkit)
Dojo Toolkit:
Dojo Toolkit是一個致力于簡化跨平臺JavaScript/Ajax應用和網站的開源模塊化JavaScript類庫. Dojo是一個面向大規模客戶端web開發的JavaScript框架. 例如, Dojo抽取出一個屏蔽各種瀏覽器差異的API集合. 此外, Dojo的功能還包含: 定義了模塊化代碼的框架, 并管理他們的相互依賴關系; 提供構建工具集, 可以用來優化JavaScript和CSS代碼, 生成文檔并且運行單測; 支持國際化, 本地化和無障礙(accessibility); 提供了豐富了通用工具類和用戶界面組件(Widget).
-
社區支持
|
|
AngularJS |
DOJO |
|
關注/收藏數 |
25760 |
300 |
|
Fork次數 |
9136 |
216 |
|
貢獻者 |
877 |
59 |
|
發布次數 |
92 |
147 |
-
MVC
Angular開發團隊已經將MVC設計模式以多種方式引入到Angular中, 因此會使得開發也必須跟隨這MVC設計模式. AngularJS并沒有以傳統的方式實現MVC, 而是更接近于MVVM(Model-View-ViewModel), 因此有時被統稱為MV*. MVC是Angular的核心, Angular為MVC設計模式提供了原生的支持, 可以輕易將其應用于web應用程序的開發中.
Dojo的Toolkit為JS應用程序提供了實現MVC的獨立工具包. Dojo并沒有為JS應用程序提供完備的MVC實現, 而是根據應用程序自身需要, 選擇性使用其中的MVC工具/組件. Dojo提供MVC功能的包是dojox/mvc.這個dojox/mvc包主要關注客戶端的View到Model的數據綁定, 僅提供了在一個View中的數據綁定/控制器的支持, 并未提供在應用程序級別的跨多個View的支持(例如, 導航(Navigation)的支持).
在Dojo中,MVC應用中的級別關注點比如路由或者導航等必須使用另一個包(dojox/app)來處理,而在AngularJS框架中,這些關注點都是框架自身就能處理的。
dojox/mvc模塊的狀態現在仍然是“Experimental” , 所以它仍然是不穩定的,正如下面這篇文章所說的(http://dojotoolkit.org/reference-guide/1.10/dojox /index.html#dojox-index),而Angular則是一個經過了更多的驗證、穩定而成熟的JS MVC框架。
-
SPA
AngularJS是一個流行的全功能的SPA框架。AngularJS的一些固有特性支持了單頁面應用的開發。Angular通過下列特性來支持SPA:
-
內嵌視圖(Nested Views)
-
控制器(Controller)繼承
-
路由(Routing)
Dojo通過其Dojox/app包實現其構建單 頁應用的目標。這個包是個小型的應用框架,提供了一組類,用于管理部署在移動設備或桌面系統上的單頁面應用的生命周期和行為。該應用框架被設計成只需簡單 配置一個配置文件,由潛在的嵌套視圖組成應用,并便于這些視圖之間的過渡。
使用Angular開發單頁面應用,可以很好的集成整個框架,同時框架提供了MVC功能,例如路由,控制器,視圖和單頁面應用模式是緊密結合的。 Dojo中的Dojox/app則是一個獨立的組件,并未將單頁面應用與MVC緊密結合,因此,Dojox/mvc在使用的時候必須通過配置Dojox /app來管理解決,而這在Angular中是自帶的,而且容易使用的。
-
UI 掛件和庫
Dojo提供了底層系統所支持的大量的widget(用戶接口組件).Dojo的UI庫稱為Dijit,使用一個單獨的命名空間"dijit".
Angular確實提供了一個UI widget工具集,但是沒有Dojo所提供的廣泛.Angular允許隨意使用流行的第三方UI庫.它提供了名為"Angular-UI"的UI庫,這 個庫包含各種流行的第三方庫的widget和模塊.其中,UI-Bootstrap模塊將Bootstrcp框架的所有widget作為Angular指 令.
由于Dojo是一個工具集,所以它的任意一個工具都可以不依賴于Dojo生態系統而單獨使用.因此,Dojo的Dijit和其他流行的UI和widget庫,如JqueryUI和其他jquery或js插件,都可以將它們包裝成指令后,在Angular應用程序中使用.
-
RESTful Interation
AngularJS使用angular-resource(ngResource)模塊來提供RESTful交互功能,該模塊表示一個REST資源并提供幫助方法(GET/POST/PUT/DELETE)來輕松的實現RESTful交互。另外也提供其它的可選模塊。
Dojo使用dojo/store/JsonRest來提供RESTful交互能力。它是一個輕量級的對象存儲實現,給那些具有RESTful數據交互能力的HTTP客戶端來使用。
AngularJS和Dojo都提供了大體相當的RESTful交互能力。
-
可維護性
AngularJS提供了一些特性,讓擁有大量代碼基數的應用程序變得可維護.這些特性如下:
-
AngularJS 鼓勵和增強最小化DOM操作,推薦只在HTML中使用的指令中展現DOM操作.這樣可以避免由于大量使用DOM和DOM事件等產生的"意大利面"式的代碼.這些代碼在大的web應用程序中難于調試和跟蹤.Angular指令也為增加了HTML語義.
-
Angular提供了一些類似模塊的特性,它允許應用程序開發者,將不同部分的應用程序邏輯打包成模塊,以增加應用程序的模塊化和可維護性.
-
Angular提供了DI (依賴注入) 設計模式的固有特性,它幫助應用程序保持模塊化和易讀性.
-
項目結構框架對于AngularJS已經可用,可以用來開發可維護的企業web應用程序.
Dojo沒有提供最小化DOM操作的技術,這樣,對于大型web應用程序,DOM操作增加了趨向于“意大利面”式代碼的可能性,也影響了應用程序的可維護性. Dojo支持模塊(AMD),但是沒有為web應用程序提供DI模式.
-
數據綁定和視圖模板化
商業web應用程序的數據中心原則要求來自模型的數據和UI同步更新.對于一個商業web應用程序,動態視圖必須依賴于模型數據而創 建.Angular提供了相當簡單和已有的技術,聲明式的編寫綁定到模塊數據的動態視圖.在Angular里面,視圖模板化使用包含Augular專有的 元素和屬性的HTML編寫.使用HTML作為模板化語言,對于開發者而言,更易于創建和理解視圖.Angular結合了來自模型和控制器的信息模板,用來 渲染用戶在瀏覽器中看到的動態視圖.Angular使用了雙向綁定特性以保持UI和模型的同步.
同樣的特性也可以在Dojo中使用,但是,它們和Dojo工具集的流程不太協調,也缺少了這個特性的簡單和細微化.
-
聲明式的用戶接口
AngularJS 提升了HTML視圖的 聲明式設計(declarative design)。在視圖層,使用HTML作為模板語言讓它變得相當容易開發創建視圖,同時也變得易于理解,在視圖語義上也有利于其他開發者。Angular提供一個特性,被稱為“directives”,它可以根據領域的需要,來提高HTML的定制性。
聲明式設計(declarative design)可以在Dojo應用中通過使用data-*屬性運行,但是它跟Angular的“directives”特性不一樣。
-
支持 AngularJS 能更好的進行 IDE 和瀏覽器調試
Netbeans IDE也為AngularJS提供了內嵌的支持,它讓使用AngularJS可以簡單的開發web應用程序.(http://wiki.netbeans.org/NetBeans_80_NewAndNoteworthy#JavaScript)
Angular團隊也為Google Chrome瀏覽器創建了一個名為Batarang的插件,它提高了使用Angular開發應用程序的調試體驗.這個插件旨在簡化性能瓶頸的檢測,以及提供GUI來調試應用程序.
-
使用Dojo的時候很難在大型團隊中保持代碼的統一
Dojo中的編程模型是使用widget,當拓展它們的時候,它們將你的代碼包圍住.你仍然在編程來操作DOM,連接/注冊/取消注冊事 件.Dojox/mvc并沒有生成模塊化的代碼.在Dojo中有多余2種或3種的方式做同樣的事情.其中一些甚至是糟糕的實踐,但是并沒有被清除.很難在 大型團隊中加強代碼的統一,因為Dojo沒有為模塊化和統一化的web應用程序提供整體的框架.
AngularJS提供了一個全面的框架,包含MVC的核心及規劃模型,具有均勻性,可理解性和模塊化。AngularJS只為模型提供嵌套的控制 器。良好的測試應用程序隔離的部分。定義良好的相關性。大部分時間你不寫代碼操縱DOM自身。但你可以在創建指令(組件)時這樣做。沒有命名空間混亂。你 的對象從來不會出現在全局命名空間中,好像一切都封裝在Angular的應用中。MVC模式是核心。你的應用程序是一套控制器,服務,過濾器和自定義指 令。
總結
本文意圖讓我們知曉web應用的未來就在眼前。并嘗試概述一個正確的有指導意義的方法來結構化和設計一個web應用,使之能適應web世界。本文概述了客戶端JS MV*框架的使用,并說明了為什么用客戶端MVC框架組織的web應用很適合實現web應用。
本文集中分析和總結了在成熟的客戶端MVC框架下的對比,并提供一些對比的統計信息,幫助你和你的團隊決策,選擇出適合你的web應用的客戶端MVC框架。
本文偏向于AngularJS框架,你可以有不同的偏好。對我來說AngularJS是我個人的喜好所在,在我眼中是其他客戶端MVC框架所不能匹敵的。