導讀：本文由機器human 編譯自 Mark Rajcok 在 StackOverflow 的同名問答題《How do I “think in Angular.js” if I have a jQuery background?》。下面是 Mark Rajcok 的提問：

“我可以熟練使用jQuery進行客戶端應用的開發，但是現在我希望開始使用Angular.js。哪位能描述一下這個過程中必要的模式變化嗎？希望您的答案能夠圍繞下面這些具體的問題：

1. 我如何對客戶端web應用進行不同方式的架構和設計？它們之間最大的區別是什么？（譯者注：指jQuery和Angular.js）

2. 有什么是我不該做或者不該使用的；而又有什么是我應該做或者應該使用的呢？

3. 有沒有一些服務端的考量/約束呢？

我在尋找的就是一個關于jQuery和Angular.js之間的詳細的比較。”

下面是來自 Josh David Miller 的最佳回答：

1. 絕不要先設計你的頁面，然后用DOM操作去改變它

在jQuery中，你會先設計一個頁面，然后讓它變得動態化。這是因為jQuery是為了擴展而設計的，并在這個前提下變得越來越臃腫。

但是在Angular.js中， 你必須從一開始就在腦子里掛著架構的弦。不要一開始就想著“我有這樣一個DOM，我想讓它做X”， 你必須從你要完成的目標開始思考，然后設計你的應用， 最后才是設計你的視圖。

2. 不要用 Angular.js 擴展 jQuery

類似地，不要一開始就帶著這樣的想法：jQuery可以完成X，Y，Z，所以我只要在其上為模型和控制器添加Angular.js就行了。在起步階段這確實很容易勾引你，這也是為什么我總是推薦Angular.js新手根本不要使用jQuery，至少要在他們習慣了“angular 方式”之后。

我在這里（譯者注：指stackoverflow）和郵件列表上看到過很多開發者，他們用150或者200行代碼的jQuery插件，然后利用一堆讓人困惑的復雜的回調和$apply與Angular.js粘合起來建立這些詳盡的解決方案；最終確實可以跑起來！ 但是其實這個問題在大多數情況下，我們可以用一小段Angular.js代碼來重寫jQuery插件即可，而這種方式會讓一切剎那間簡單明了可理解。

我覺得這類問題的底線是：當你在解決問題時，首先利用“Angular.js思想”去做；如果你不能想出一個方案，那么就在社區里詢問；如果還是沒有簡單的解決方法，那么再請隨意使用jQuery吧。但是注意，千萬別讓jqeury成為你的拐杖，不然你將永遠無法真正精通Angular.js。

3. 永遠根據架構去思考

首先你要知道，單頁面結構也是應用。它不是網頁。所以我們需要有服務端開發者思想加上客戶端開發者思想。 我們必須考慮如何將我們的應用拆分為獨立，可擴展，可測試的組件。

那么你要怎么做呢？你如何做到利用“angualrjs思想”呢？這里有一些普遍的原則，與jQuery作為比照。

視圖是“正式記錄”

在jQuery中，我們通過編程方式來改變視圖。我們可以像下面這樣通過ul標簽來定義一個下拉菜單：

<ul class="main-menu"> 
    <li class="active"> 
        <a href="#/home">Home</a> 
    </li> 
    <li> 
        <a href="#/menu1">Menu 1</a> 
        <ul> 
            <li><a href="#/sm1">Submenu 1</a></li> 
            <li><a href="#/sm2">Submenu 2</a></li> 
            <li><a href="#/sm3">Submenu 3</a></li> 
        </ul> 
    </li> 
    <li> 
        <a href="#/home">Menu 2</a> 
    </li> 
</ul> 

在jQuery中，根據我們應用的邏輯，可以用類似下面的語句來激活它。

$('.main-menu').dropdownMenu(); 

當我們只是看著視圖的時候，不會立刻看出它的功能。對于小應用而言，這樣是沒問題的。但是對于大型的應用，情況就一下子變得令人困惑并且難以維護。

但是在Angular.js中，視圖是基于視圖的功能的正式記錄。我們的ul是像下面這樣聲明的：

<ul class="main-menu" dropdown-menu> 
    ...  
</ul> 

這兩者其實做了同樣的事情，但是在Angular.js的版本中，任何看到這個模板的人都知道將要發生什么。不論何時，開發團隊里有任何新的開發人員加入，她可以一眼看出有一個叫做dropdownMenu的指令作用在視圖上；她根本不需要憑直覺猜測或者研究下代碼才找到正確的答案。視圖本身就告訴我們將會發生什么了。清晰多了。

angualrjs的新手經常會問這樣一個問題： 我如何找到某一類所有的鏈接并且給它們添加一個指令呢？當看到我們回復的時候小伙伴都震驚了：壓根別去這樣做。但是勸你不要這樣做的原因是，這樣做就像是一半jQuery，一半angulrjs，而這真心很糟。這里的問題是，開發者想在angualrjs的情境中使用jQuery方式。而這絕對不會玩得轉。視圖是正式記錄。超出指令的范圍（這點下文會談論更多），你絕不要去改變DOM。而且指令是應用在視圖中的，目的自然也一目了然。

記?。翰灰仍O計再修飾。你必須先進行架構，然后再考慮設計。

數據綁定

這是Angular.js目前最酷的特性之一，并且秒殺我前文提到的各種需要的DOM操作。不需要你自己動手，Angular.js將自動更新你的視圖有木有!

在jQuery里， 我們響應事件并更新內容，大概是這個樣子：

$.ajax({  
  url: '/myEndpoint.json',  
  success: function ( data, status ) {  
    $('ul#log').append('<li>Data Received!</li>');  
  }  
}); 

視圖則看上去是這樣的：

<ul class="messages" id="log"> 
</ul> 

除了關注點混合的問題，這里同樣有之前提到的表征目的的問題。更重要的是，我們不得不手動引用并更新dom節點。并且如果我們想要刪除一個日志，我們不得不再次對dom編程操作。我們怎樣才能拋開dom來測試邏輯呢？還有，如果我們希望改變展現呢？

#p#

真是讓人凌亂。。。

但是在Angular.js中，我們可以這樣做：

$http( '/myEndpoint.json' ).then( function ( response ) {  
    $scope.log.push( { msg: 'Data Received!' } );  
}); 

我們的視圖看上去是這樣的：

<ul class="messages"> 
    <li ng-repeat="entry in log">{{ entry.msg }}</li> 
</ul> 

但是考慮到剛才提到的問題，我們的視圖看上去可以是這樣的：

<div class="messages"> 
    <div class="alert" ng-repeat="entry in log"> 
        {{ entry.msg }}  
    </div> 
</div> 

現在，替換掉了無序列表，我們使用Bootstrap警告框。同時我們根本不需要改變控制器代碼！更重要的是，不論日志何時或者如何更新，視圖也會跟著改變。自動的！漂亮！

雖然我沒有在這里演示出來，但是數據綁定是雙向的。所以這些日志信息同樣可以在視圖中被編輯，就像這樣：

<input ng-model="entry.msg" /> 

是不是更開心了？

不同的模型層

在jQuery中，dom有點像模型。但是在angualrjs中，我們有一個分離的模型層， 而這個模型層可以讓我們用任何方式管理，完全獨立于視圖。這對于上面說的數據綁定很有幫助， 還可以維護關注點分離，并且引入更多的可測試性。其它的答案提到了這點，所以我這里就不再贅述了。

關注點分離

以上所有的這些把我們帶入了這樣的主題：保持你的關注點分離。你的視圖表現的像記錄什么會發生（大部分情況）的正式記錄；你的模型表現你的數據；你有一個服務層來執行可重用的任務；你執行dom操作并通過指令擴展你的視圖；并且你用控制器來組合這些。這些同樣已經在其它答案中提到，我在這里唯一還要提出的一個事情就是可測試性，我會在下文的另一節里專門討論。

依賴注入

依賴注入是讓我們實現關注點分離的方法。如果你是一個服務器端的開發者（從java到php），你可能對這個概念已經非常熟悉了，但是如果你是一個來自jQuery的客戶端的朋友，那么你可能會認為這個概念是傻淺挫。但是它可不是：）

從一個更廣的觀點來看， 依賴注入意味著你可以非常自由的聲明組件，然后你可以通過任意其它組件，呼叫一個它的實例，然后授權。

你不需要知道載入順序，或者文件位置，或者其它類似的東西。這種強大的力量可能不會立刻顯現，但是我這里會提供一個（通常）的例子：測試。

比如在我們的應用中，需要一個通過REST API，同時也依賴于應用狀態，本地存儲實現了服務器端存儲的服務。當在我們的控制器上跑測試的時候，我們不希望與服務器端通訊-畢竟我們在測試控制器。我們能夠僅僅添加一個與我們原始組件同名的mock服務，注入器將確保我們的控制器自動獲取偽造對象–我們的控制器不會也不需要知道它們的區別。

那么既然提到測試……

4. 保持測試驅動的開發

這個其實是關于架構的第三節的一部分，但是這個主題非常重要，所以我需要將其提出來作為自成體系的部分。

那些你看過，用過，寫過的所有jQuery插件，它們中有多少有相應的測試包？不是很多吧？ 因為jQuery可不是很遵守這個規矩。但是angualrjs是。

在jQuery中， 測試的唯一方法是用示例頁面來獨立地創建組件，針對該頁面我們的測試可以實施dom操作。于是我們就不得不分離地開發一個組件然后將其集成進我們的應用。多么不方便??！

那么多時間啊，當我們使用jQuery開發時，我們選擇使用迭代開發代替測試驅動的開發?？梢哉l又能怪我們呢？

但是因為我們有關注點分離，我們能夠在Angular.js里反復使用測試驅動開發。舉個例子，我們想要一個超簡單的指令來指示在菜單中我們目前的路徑是什么。我們可以在視圖中這樣聲明我們想獲取的：

<a href="/hello" when-active>Hello</a> 

好了，我們現在可以寫個測試：

it( 'should add "active" when the route changes', inject(function() {  
    var elm = $compile( '<a href="/hello" when-active>Hello</a>' )( $scope );  
   
    $location.path('/not-matching');  
    expect( elm.hasClass('active') ).toBeFalsey();  
   
    $location.path( '/hello' );  
    expect( elm.hasClass('active') ).toBeTruthy();  
})); 

我們運行測試，并確認它是失敗的。那么我們來寫下我們的指令：

.directive( 'whenActive', function ( $location ) {  
    return {  
        scope: true,  
        link: function ( scope, element, attrs ) {  
            scope.$on( '$routeChangeSuccess', function () {  
                if ( $location.path() == element.attr( 'href' ) ) {  
                    element.addClass( 'active' );  
                }  
                else {  
                    element.removeClass( 'active' );  
                }  
            });  
        }  
    };  
}); 

現在我們的測試通過了，并且我們的菜單按照請求運行。我們的開發是迭代并且測試驅動的，太酷了哦！

#p#

5. 從概念上來看，指令不是打包的jQuery

你會經常聽到“只在指令里做dom操作”。這是必要的。請對它表示出尊重！

但是讓我們談點更深入的。。。

一些指令只是裝飾那些在視圖里的已有的（想想ngClass），因此有時候就直接進行dom操作，基本上都能搞定。但是如果一個指令像個“widget”并有一個模板，

那它同樣要遵守關注點分離原則。也就是說，這個模板也應該與它在鏈接和控制器函數里的實現保持最大的獨立。

Angular.js自帶著一套工具讓這件事變得簡單； 使用ngClass我們能夠動態的更新類；ngBind允許雙向的數據綁定；ngShow和ngHide以編程的方式顯示或隱藏一個元素；還有更多–包括我們自己寫的那些。換句話說， 我們可以不用DOM操作來實現所有的酷炫的事兒。 dom操作越少，指令越容易測試，它們也更容易樣式化，在未來它們也更容易改變，并且也變得更加可重用和可分發。

我看到很多Angular.js開發新手將指令當做放置一堆jQuery的地方。換句話說， 他們認為：“既然我不能在控制器里做dom操縱，那么我就把這段代碼放到指令里”。當然這看上去好多了，但是通常這仍然是錯的。

想一下在第三節里我們編寫的日志記錄。即使我們將其放到一個指令里，我們仍然希望用“anggualjs方式”來做這件事情。這仍然沒有做任何 dom操作！在很多情況下dom操作是必須的，但是這種情況其實比你想的少得多！在你在你的應用中到處使用dmo操作之前，問問你自己，這真的是必須的嗎?？赡苡懈玫姆椒亍?/p>

這里用一個簡單的例子來展示我們經常會看到的一個模式。我們需要一個切換按鈕。（注意：這個例子有那么一點人為設計的技巧并且有點啰嗦，但是很多更復雜的情況其實也完全可以根據這個例子的方式來解決。）

.directive( 'myDirective', function () {  
    return {  
        template: '<a class="btn">Toggle me!</a>',  
        link: function ( scope, element, attrs ) {  
            var on = false;  
   
            $(element).click( function () {  
                if ( on ) {  
                    $(element).removeClass( 'active' );  
                }  
                else {  
                    $(element).addClass( 'active' );  
                }  
   
                on = !on;  
            });  
        }  
    };  
}); 

這里有一些錯誤。第一，jQuery不是必須的。我們這里做的一切都不需要jQuery！第二， 即使是我們的頁面上已經有jQuery，也沒有理由一定要在這里使用它；我們可以簡單的使用angular.element，而且就算在一個沒有 jQuery的項目中我們的組件仍然可以工作。第三，即使我們假設為了讓這個指令工作，jQuery是必須的，如果jqury被加載，那么 jqLite（angler.element）一定會使用jQuery。所以我們不需要使用$（譯者注：jQuery的一個標識符號，是jQuery函數的別名）–我們可以使用angular.element。第四， 緊接第三點，jqLite元素不需要被包裹在$里–傳遞給link函數的element已經是一個jQuery元素！第五， 我上一節已經提過的，為什么我們要將模板混合進我們的邏輯呢？

這個指令可以更精簡的重寫（即時在更復雜的例子里也一樣）：

.directive( 'myDirective', function () {  
    return {  
        scope: true,  
        template: '<a class="btn" ng-class="{active: on}" ng-click="toggle()">Toggle me!</a>',  
        link: function ( scope, element, attrs ) {  
            scope.on = false;  
   
            scope.toggle = function () {  
                scope.on = !$scope.on;  
            };  
        }  
    };  
}); 

再次強調，模板的那些代碼都是在模板里的，所以你或者你的使用者能夠很方便的將其換成一個符合任何需要的樣式，同時邏輯不被改變。這就是重用性-贊！

當然，還有其它很多好處–比如測試 – 這很容易！ 不論什么在模板中，指令的內部API絕不會被接觸，所以重構就變得容易。你可以在不接觸指令的情況下隨意改變你的模板。并且不論你怎么變，你的測試仍可以通過。

耶！

所以如果指令不只是一組jQuery風格的函數，那么它們是什么呢？指令其實就是html的擴展。如果html不能完成你希望它做的一些事情，你就寫一個指令來做，并且當它是html的一部分來使用。

換句話說， 如果Angular.js一下子無法完成手頭的工作，想想看你的團隊是否能用ngClick、ngClass等來搞定它。

總結

別用jQuery。甚至都別引用它。它會阻礙你。當你有個問題已經知道怎么用jQuery來解決的時候，在你將手伸向$的時候，試試能不能在Angular.js的規范內解決。如果你不知道，就問！

十有八九最佳的方法是不需要jQuery的，而當你選擇用jQuery的時候反而會導致更多的工作呢。

原文鏈接： stackoverflow   翻譯： 伯樂在線 - jiqihuman

譯文鏈接： http://blog.jobbole.com/46589/