本文翻譯自國外網站，老外羅裡吧嗦的講了一堆，關鍵就10點理由，概括為一點：Angular是很好的工具包，值得你好好學習。^_^

原文地址：

https://www.codeproject.com/Articles/718046/Reasons-Web-Developers-Should-Learn-Angular

有興趣的可以看一看引文版。

下面就看看所謂的10大理由吧……

0-引言

毫無疑問，AngularJS--自稱為"超級英雄JavaScript框架" - 正在增強吸引力。 我會在這篇文章中經常將它稱為"Angular"。 我有幸在一個大型團隊（近10位開發人員，很快增長到20位以上）使用Angular的企業Web應用程序上工作超過半年。 更有意思的是，我們在開始使用純JavaScript和KnockoutJS的更傳統的MVC/SPA方法之後，開始使用TypeScript和Angular的功能組合。 需要注意的是，我們使用Jasmine添加了全面的測試，但整體而言，團隊認同這些技術組合提高了我們的質量和效率：我們看到的bug更少，功能更快。

如果你熟悉Angular，這篇文章可能會給你一些想法，想想你以前沒有遇到過。 如果您瞭解Angular並試圖證明您在公司或您的項目中採用Angular的理由，本文可為您提供一些可能有所幫助的背景信息。 如果您不知道Angular是什麼，請繼續閱讀，因為我將分享為什麼它如此強大，然後將您的資源指向可快速提高速度的資源。

我只能假設其他組織在採用Angular之後會看到積極的結果。 根據谷歌趨勢，與KnockoutJS（紅色）和"單頁應用程序"（黃色）相比，AngularJS（藍色）的普及正在爆炸式增長。

首批單軌AngularJS大會之一ng-conf在短短几分鐘內售罄了數百張門票。 參加會議時，我瞭解到Angular正在用於各種基於網絡的應用程序，包括Google自己的Doubleclick Campaign Manager（DCM）等大量企業Web應用程序。

本文不打算打擊KnockoutJS或Ember或Backbone或任何其他您可能已經使用且熟悉的流行框架。 相反，我想重點關注為什麼我相信Angular如此迅速地獲得如此巨大的發展勢頭，並且任何從事Web應用程序工作的人都應該非常認真地對待，並且至少要更多地瞭解如何將它放入您的應用程序工具箱中。

1-Angular數據綁定

這可能聽起來像口水般的服務，但我已經參與了很多項目，並已看到它在行動。 我記得兩個具體的例子。 一個是與微軟合作的項目，我們不得不在大約4個月內完成。 我們估計一個長達4個月的動手開發和一個單獨的設計團隊需要大約4個月的設計才能完成所有的工作 - 他們從線框到互補模型以及運動研究和其他讓我感謝的術語 -當我專注於代碼時，我可以讓設計人員做到這一點。 當然，如果我們遵循傳統的順序方法，我們會錯過最後期限並等待8個月（設計4個月，然後是4個月的編碼）。 XAML允許我們並行工作，通過同意屏幕界面 - "這些是我們將要公開的內容。"開發人員致力於獲取數據以使這些屬性可用並編寫所有測試，並且 設計師們將這些元素進行了操控，動畫化，並將它們移動到了所需的設計中，最後它們都出色地匯合在了一起。

另一個現實的例子是一個電纜公司的試點項目。 我們正在構建基於Silverlight的交互式指南的版本。 可唯一的問題是他們還沒有準備好API。 我們能夠根據映射用戶體驗內容的域模型（列表，時間等）設計系統，然後在API定義好和可用後，用API填充這些域對象。 同樣，它啟用了並行工作流程，極大地提高了我們的效率和設計的靈活性。

我在Angular框架中看到了這些相同的原則。 它支持分離關注點，從而允許在各種組件之間建立真正的並行工作流，包括UI本身的標記以及獲取和處理數據的基礎邏輯。

2-Angular擺脫陳規和儀式

你有否想在一個模型上創建一個文本屬性綁定到你的UI的模型上？ 這在各種框架中如何完成的？ 在Angular中，這將毫無問題地生效，並立即反映在你的span內：

{{synchronizeThis}}

雖然我知道其他一些框架已經越來越好了，但是離開我們現有的框架，我們必須明確地將所有內容映射到臨時對象，以便將數據綁定到Angular，就像一股清新的空氣......事情剛剛開始更加融洽-很快，我覺得我正在複製較少的代碼（誰想要定義一個聯繫人表，然後是服務器上的聯繫人域對象，然後聯繫人JSON對象，然後必須傳遞給聯繫人客戶端模型——顯示關於聯繫人的詳細信息？）

意思為綁定省略了很多模式化冗餘代碼或步驟。

3-Angular依賴注入

依賴注入是Angular做得很好的事情。 我承認我對此持懷疑態度，甚至在客戶端需要類似的東西，但我習慣於關鍵場景是模塊的動態加載。 哦，等等 - 你說什麼？ 沒錯，像RequireJS這樣的圖書館，你可以在需要時動態加載JavaScript。 但是依賴注入真正發揮有兩種情況：測試和單頁應用程序（SPA）。

為了進行測試，Angular允許您將應用程序劃分為邏輯模塊，它們可以彼此依賴，但是分別進行初始化。 這讓你只需引入你感興趣的模塊就可以對你的測試採取非常有策略的方法。然後，因為依賴關係被注入，你可以使用Angular的$http服務等現有服務，並使用$httpBackend mock替換它來測試。 這使得真正的單元測試不依賴於服務，或者瀏覽器UI來呈現，同時也擁有創建端到端測試的能力。

SPA（單頁應用程序）使用從基於Web的app中動態加載呈現出地道的"本地應用"的感覺。 人們喜歡大聲說SPA的縮寫，因為它是新的東西，但我們一直在構建Atlas和Ajax時代的那些風格應用程序。 很諷刺的是，儘管事實上很少有XML涉及，但因為它全部是JSON，所以現在認為Ajax是真正推動SPA的東西。 你會發現這些應用可以快速增長，並且對各種服務和模塊有很多依賴。 Angular可以很容易地組織這些並根據需要抓取它們，而不用擔心諸如"它生活在什麼名稱空間中？"或"我已經創建了一個實例？"而只是告訴Angular您需要什麼，Angular會如何 併為您獲取它併為您管理對象的生命週期（例如，您不會使用獲取該聯繫信息的同一簡單服務的100個副本運行）。

使用DI連接相關服務的示例：

var $$jsInject = new WintellectJs.$$jsInject();

$$jsInject.register("car", [Car]); // annotating deps at registration

$$jsInject.register("tires", ["engine", Tires]);

$$jsInject.register("engine", ["gas", Engine]);

$$jsInject.register("gas", [Gas]);

Car.$$deps = ["engine", "tires"]; // annotating deps on class

var car = $$jsInject.get("car");

console.log(car.drive());

要真正理解依賴注入的工作方式，請看看我創建的簡單$$jsInject解決方案(https://github.com/jeremylikness/jsinject)。 它使用類似於Angular的語法，但將它全部提煉成100行以下的代碼。 你可以在這裡(http://jsfiddle.net/jeremylikness/tKHmT/)為它運行相關的測試。

5-Angular擁抱測試驅動開發

無論您採用測試驅動開發、行為驅動開發還是任何驅動開發方法，Angular都支持這種構建應用程序的方法。 我不想用這篇文章來探討你應該採用測試開發方式的所有優點和原因（我真的很驚訝，在2013年，人們仍然質疑價值），但我最近採取了更多的傳統" 測試第一"的方法，這是有幫助的。 我相信在我們的項目中，Jasmine的引入以及我們所包含的測試都有助於將缺陷減少高達4倍。 也許更少（或可能更多），但下降顯著。 這不僅僅是因為Angular——它是需求、好的接受標準、理解如何正確編寫測試、以及讓框架運行它們的組合——但它確實更容易構建這些測試。

這是一個測試示例，顯示Angular視圖模型或"範圍"的繼承：

it("overrides from the parent", inject(function ($rootScope) {

 var scope = $rootScope.$new();

 var childScope = scope.$new();

 scope.a = 1;

 scope.b = 2;

 childScope.b = 3;

 expect(scope.$eval('a+b')).toBe(3);

 expect(childScope.$eval('a+b')).toBe(4);

}));  

如果你想看這像什麼，看看我的6502模擬器，然後瀏覽源代碼。 除了一些最初的管道外，該應用程序是用純粹的測試優先方法編寫的。 這意味著當我想添加一個操作代碼時，我會為操作代碼編寫測試，然後圍繞它並實現之。 當我想要擴展編譯器時，我編寫了一個測試，以驗證編譯失敗的結果，然後重構編譯器以確保測試通過。 這種方法為我節省了時間，並且既改變了我對應用程序的結構和思考方式，也為文檔創建了文檔 - 您可以自己查看規範並理解代碼應該執行的操作。 模擬依賴並將它們注入到Angular中的能力非常重要，正如您從示例中所看到的，您可以測試從UI行為到業務邏輯的所有內容。

6-Angular支持大規模並行開發

我們在項目早期遇到的最大問題之一是開發人員踩在彼此的腳趾上。 其中一部分只是一門學科，即使使用原始JavaScript，您也可以遵循使其更加模塊化的模式，但Angular將它提升到另一個級別。 這並不是說它完全消除了依賴性，但它確實使它們更易於管理。 作為一個具體的例子，應用程序中有一個巨大的網格用於驅動幾個關鍵操作。 在一個傳統的JavaScript應用程序中，在一個龐大的團隊中進行擴展，這可能是一個合併的惡夢。 然而，通過Angular，將各種操作分解成自己的服務和子控制器非常簡單，開發人員可以獨立地測試和編寫代碼，而不會像往常一樣崩潰。

很顯然，對於大型項目來說，這是關鍵。 從它如何在客戶端實現某些功能的角度來看，這不僅僅是關於技術，而實際上它是如何實現工作流程和處理過程，以便能夠擴展團隊。

7-Angular支持設計到開發雙向工作流機制(Designer Developer)

好的，我在開玩笑吧？ 您可以通過HTML和CSS以及其他有趣的技術獲得此信息。 然而，其得到自己的子彈的原因是因為它與Angular的協調工作的很好。 設計師可以添加標記而不會完全破壞應用程序，因為它依賴於某個ID或結構來定位元素並執行任務。 相反，重新安排部分代碼就像移動元素一樣簡單，並且綁定和過濾的相應代碼也隨之移動。 儘管我還沒有看到開發人員與UI / UX團隊共享"設計合同"的靈敏環境，但我並不懷疑它離得很遠 - 基本上這些團隊就將要顯示的元素達成一致意見， 然後將其展示出來，儘管他們希望在$scope中使用其控制器和其他邏輯進行開發連接，最後這兩個部分才會結合在一起。 我們用XAML做到的，沒有什麼能夠阻止你對Angular做同樣的事情。

如果您是Microsoft開發人員並曾與Blend合作......看到了解Angular的IDE，並且可以提供用於設置綁定和設計時數據的UI，這不是很酷嗎？ 這種能力在那裡，它只是需要建立，隨著所看到的人氣，我不相信這會花費很長時間。

8. Angular提供控制模板（Directives"指令"）

我聽說過有關轉向MVC的最常見的抱怨之一是"我們對所有這些控件怎麼處理？"早期認為控件不起作用/不會在非ASP.NET空間中運行，而是使用其他平臺的web 開發人員知道情況並非如此。 有多種方法可以在Web上引入可重用代碼，從jQuery插件的概念到像我最喜歡的KendoUI之類的第三方控件供應商。

Angular啟用了一種稱為"指令"(directive)的新方案，允許您創建新的HTML元素和屬性。 在早期的T6502示例中，"data-ng-model"指令允許進行數據綁定。 在我的模擬器中，我使用一個指令來創建兩個新標籤：一個用於編寫控制檯消息的"控制檯"標籤和一個使用SVG為模擬器渲染像素的"顯示"標籤（如果您已經 檢查出來，我意識到它更像一個模擬器）。 這為開發人員提供了控制 - 更重要的是控制了控件。

我一直在做的一個項目已經發展了幾十個指令，他們都加入了以前的觀點:

•指令是可測試的

•指令可以並行處理

•指令減少陳規和儀式

•指令參與依賴注入

請記住我是如何提到該項目的巨多網格的？ 我們碰巧使用了很多網格（幾乎所有企業Web應用程序都是這樣寫的）。 我們使用KendoUI變體，並且您必須採取幾個步驟來初始化網格。 就我們的目的而言，許多配置選項在網格中是一致的，那麼為什麼讓開發人員輸入所有的代碼呢？ 相反，我們使他們能夠刪除一個新的元素（指令），用一些屬性（指令）標記它們，並且它們已經啟動並正在運行。

9. Angular幫助管理狀態

我更多地指的是客戶端狀態，以及如何在瀏覽器中管理應用程序中的屬性、權限和其他常見交叉問題。 Angular不僅處理依賴注入，還為您管理組件的生命週期。 這意味著你可以用完全不同的方式處理代碼。 這裡有一個簡單的例子來解釋我的意思:

應用程序的其中一部分涉及複雜的搜索。 這是一種傳統模式：輸入您的搜索條件，單擊"搜索"並查看包含結果的網格，然後單擊一行即可查看詳細信息。 最初的實現包含兩個頁面：第一個是詳細的標準頁面，然後是一個帶有窗格的網格頁面，可從右側滑入以顯示當前選定行的詳細信息。 在項目後期，這被重構為覆蓋網格本身的搜索條件的對話框，然後是單獨的全屏頁面以獲取細節。

在傳統的Web應用程序中，這將涉及重寫一些邏輯。 我可能會有一些調用會獲取詳細信息，並希望在同一頁面上將它們傳遞給面板以獲取詳細信息，然後突然必須重構該信息以將詳細信息ID傳遞到單獨的頁面並讓該頁面進行調用 等等。如果你已經為網絡開發了無數時間，那麼你必定經歷一些重寫，這些重寫感覺他們對於移動東西有點多。 有多個"狀態"要管理，包括顯示詳細記錄的選擇標準和標識符。

在Angular中，這是一件輕而易舉的事情。 我為搜索對話框創建了一個控制器，為網格創建了一個控制器，併為詳細信息頁面創建了一個控制器。 一個父類控制器跟蹤搜索標準和當前細節。 這意味著從一種方法切換到另一種方法，真的意味著只需重新組織標記。 我將細節移至新頁面，將標準切換為對話框，並且我必須編寫的唯一真實代碼是在請求時調用對話框的新函數。 所有其他邏輯 - 獲取和過濾數據並顯示它 - 保持不變。 這是一個快速的重構。 這是因為我的控制器不關心頁面是如何組織或流動的 - 他們僅僅關注獲取信息並通過示波器展示信息。 該組織是一個關於路由的問題，我們使用Angular的路由機制來"重新路由"到新的方法，同時在UI之後保留相同的控制器和邏輯。 即使搜索標準的標記保持不變 ，它只是從整頁的模板更改為在對話框中使用的模板。

當然，由於應用程序是混合單頁應用程序（SPA），因此可能會進行此類重構。

10. Angular支持單頁面應用

如果你錯過了，這一點繼續最後一個理由。 單頁應用程序因為一個很好的理由而變得越來越流行。 它們滿足了一個非常特殊的需求。 更多的功能正在被轉移到網絡上，瀏覽器最終意識到了它作為分佈式計算節點的潛力。 通過設計，SPA應用程序反應更加敏捷（即使其中一些是感知）。 他們可以提供一種感覺就像在網絡上的本地應用程序。 通過在客戶端渲染，他們減少了服務器上的負載，並減少了網絡流量 - 而不是發送整頁標記，您可以發送數據負載並將其轉化為客戶端的標記。 當然，Angular並不強迫你構建SPA應用程序，它只提供大量內置支持。

根據我的經驗，大型應用程序更適合構建混合SPA應用程序。 我的意思是，將整個應用程序視為一個單頁面應用程序，將其劃分為貫穿系統的邏輯工作單元或路徑（"活動" ）。最終會導致整個頁面刷新某些區域，但主要交互發生在一系列不同的SPA模塊中。 例如，聯繫人可能是一個"迷你"SPA應用程序，而產品則是另一個。

結論

我經常聽到Angular被稱為框架。 儘管可以這樣使用它，但我認為它更像是一個庫和工具集。 它提供了諸如數據綁定之類的競爭庫功能，還增加了依賴注入，輸出過濾和通過指令的高級模板。 Angular的真正亮點在於允許您構建自己的模塊，可重用的JavaScript，然後將其插入庫中以與其他組件交互。 在最近的一次採訪中，我將Angular描述為可以編織應用程序組件以提供最終體驗的結構。 這很重要，因為它不會將您完全鎖定到框架中，並且正如我自己的團隊所經歷的那樣，可以輕鬆將現有應用程序遷移到使用Angular的應用程序。

閱讀更多 3T教育編程猿 的文章

關鍵字: XAML Google 羅裡