AngularJS與Backbone誰更適合 | 皓眸IT

看見就非常 2015-04-23

展開全文

哪個框架更適合

將不同的思想和工具進行對比，是一種更好地理解它們的方式。在本文中，我首先將列舉在創(chuàng)建web應(yīng)用程序時需要重復進行的各項任務(wù)，隨后為你展現(xiàn)Backbone和Angular將如何幫助你完成這些工作。

轉(zhuǎn)載請注明出處：http://www./2015/03/09/2015_backbone_angular/

我們所嘗試解決的問題

作為web開發(fā)者來說，我們的大部分工作都可以歸結(jié)于以下的某個類別中：

實現(xiàn)業(yè)務(wù)邏輯
構(gòu)建DOM
實現(xiàn)視圖邏輯（聲明式與命令式）
在模型與視圖間進行同步
管理復雜的UI交互操作
管理狀態(tài)和路由（routing）
創(chuàng)建與連接組件
如你所料，大多數(shù)客戶端框架都以某種方式幫助你完成這些工作。

backbone做了些什么

首先讓我們看看Backbone為解決這些問題提供了哪些功能：

皓眸哥

將最原始的Backbone與Angular直接進行對比有些不太公平，因此在本文中所指的Backbone實際上是Backbone + Marionette + 插件的這套組合。

業(yè)務(wù)邏輯

Backbone應(yīng)用程序中的很大一部分業(yè)務(wù)邏輯由模型（model）和集合（collection）負責實現(xiàn)，這些對象往往對應(yīng)著服務(wù)端后臺的資源，它們將包含視圖顯示所必須的內(nèi)容。

由于使用者必須擴展Backbone.Model和Backbone.Collection對象，因此造成了許多額外的復雜性。

首先，Backbone使用POJO（簡單JavaScript對象）和Backbone model對象兩種方式表現(xiàn)領(lǐng)域?qū)ο?。在顯示模板（template）、或是與服務(wù)端交互時需要使用POJO，而在需要使用可觀察（observable）屬性時（例如需要建立數(shù)據(jù)綁定的時候），則需要使用Backbone模型。

其次，Backbone推薦你使用不可變對象。由于Backbone不支持對函數(shù)進行觀察，因此每次有某個屬性發(fā)生改變時，與之相對應(yīng)的推斷（computed）屬性必須被重置。這就為你的應(yīng)用增加了許多額外的復雜性，也使得最終產(chǎn)生的代碼難以理解和測試。除此之外，所有的依賴項必須以（”change:sourceProperty, this.recalculateComputedProperty）的形式顯式地進行指定。

構(gòu)建DOM

Backbone使用模板引擎構(gòu)建DOM。雖然從理論上說，你可以選擇你所中意的引擎，但基本上在大型應(yīng)用程序中都會在Mustache和Handlebars這兩者之間進行選擇。Backbone中的模板定義通常不包含邏輯，并且多數(shù)是基于字符串的，不過這兩點也并非必需。

視圖邏輯

將視圖邏輯劃分為命令式與聲明式邏輯是一種由來已久的方式（可以追溯到原始的MVC模式）。事件處理配置和數(shù)據(jù)綁定屬于聲明式，而事件處理本身則是屬于命令式。不過Backbone并沒有為這兩者劃分出一條清晰的界限，它們都由Backbone.View對象處理。

在模型與視圖間進行同步

由于Backbone在本質(zhì)上追求最簡化，因此它本身并沒有為數(shù)據(jù)綁定提供支持。這一點對于小型項目來說或許不是一個問題，畢竟你可以選擇讓視圖負責對模型和DOM進行同步。但當應(yīng)用程序的功能開始不斷增加時，這種方式就很容易漸漸失控。

好在如今已經(jīng)有各種各樣的插件（例如Backbone.Sticklt）能夠幫助Backbone解決這一問題了，因此你可以不用再理會瑣碎的模型-視圖同步操作，而是專注于復雜的交互工作。這些插件中的大多數(shù)都可以使用簡單的JavaScript進行配置，因此使用者可以在它的基礎(chǔ)之上創(chuàng)建一個抽象層，以滿足你應(yīng)用程序的需求。

在Backbone中使用數(shù)據(jù)綁定的一個缺點就是它們依賴于可觀察屬性，而另一方面，模板引擎又是使用POJO實現(xiàn)的。由于同時存在著兩種與DOM交互的方式，經(jīng)常會造成代碼的重復。

管理復雜的UI交互操作

所有的UI交互操作都可以劃分為簡單交互操作（使用觀察者同步（Observer Synchronization）方式進行管理）和復雜交互操作（必須使用流同步（Flow Synchronization）方式）兩種類別。

如前文所述，簡單交互操作是通過使用數(shù)據(jù)綁定和事件處理函數(shù)的Backbone.View進行處理的。由于Backbone本身沒有硬性規(guī)定處理復雜UI交互的解決方案，你可以隨意選擇最適合你的應(yīng)用的方式。有些人選擇使用Backbone.View作為解決方案，但我建議你不要這么做，因為這種方式會造成Backbone.View的職責過多。我會傾向于使用主動控制顯示（Supervising Presenter）模式管理復雜的交互操作。

管理狀態(tài)和路由

Backbone包含了一個非常簡單的路由器的實現(xiàn)，但它并不支持管理視圖和應(yīng)用狀態(tài)的功能，必須要手動實現(xiàn)這些功能。因此在實際應(yīng)用中經(jīng)常會選擇使用其它類庫（例如router.js），而不是它自帶的路由器。

創(chuàng)建與連接組件

在Backbone中，你可以自由選擇最適合你的應(yīng)用的方式創(chuàng)建并連接組件。這種方式的缺陷在于你必須編寫大量的樣板代碼，而且為了保持代碼的合理組織，必須始終遵循良好的代碼規(guī)范。

Angular做了什么

現(xiàn)在讓我們來比較一下，看看Angular是如何解決這些問題的。

皓眸哥

業(yè)務(wù)邏輯

由于Angular沒有使用可觀察屬性，因此在實現(xiàn)模型時沒有這方面的限制。你不需要擴展某個類、或者遵循某個接口，而是可以自由地選擇你喜歡的方式（包括使用現(xiàn)有的Backbone模型）。在實際開發(fā)中，多數(shù)開發(fā)者選擇使用簡單的JavaScript對象（POJO），這種方式有以下優(yōu)點：

所有的領(lǐng)域?qū)ο蠖疾灰蕾囉谌魏翁囟ǖ目蚣埽蚨菀自诓煌膽?yīng)用中重用。
POJO對象和與服務(wù)端交互的對象非常近似，因而簡化了客戶端與服務(wù)器的通信。
POJO對象將用于視圖表示，因此無需實現(xiàn)toJSON方法。
推斷屬性可以用函數(shù)的形式表現(xiàn)

模板與視圖

所有的領(lǐng)域?qū)ο蠖疾灰蕾囉谌魏翁囟ǖ目蚣?，因而更容易在不同的?yīng)用中重用。
POJO對象和與服務(wù)端交互的對象非常近似，因而簡化了客戶端與服務(wù)器的通信。
POJO對象將用于視圖表示，因此無需實現(xiàn)toJSON方法。
推斷屬性可以用函數(shù)的形式表現(xiàn)

構(gòu)建DOM

Backbone將DOM的構(gòu)建與視圖邏輯進行了清晰地分離，前者使用模板引擎實現(xiàn)，而后者則使用數(shù)據(jù)綁定與命令式的DOM更新操作實現(xiàn)。與之相反，Angular并未將這兩者進行區(qū)分，它使用相同的機制和指令（directive）構(gòu)建DOM，并定義聲明式的視圖行為。

視圖邏輯

Angular對聲明式與命令式的視圖邏輯進行了清晰的劃分，前者由視圖處理，而后者由控制器負責。

這種劃分看起來似乎有些刻意，但它確實是非常重要的。

首先，這種方式清晰地指出了哪些部分需要進行單元測試。嵌入在模板中的聲明式邏輯（例如ng-repeat）無需進行單元測試，反之，為控制器編寫單元測試通常是個好主意。

其次，所有的依賴都是單向的，即視圖依賴于控制器，因此控制器并不了解視圖或DOM的任何邏輯。這種方式促進了代碼重用，也簡化了單元測試。與之相反，Backbone.View經(jīng)常需要對DOM節(jié)點進行操作，隨后使用模板引擎對頁面中的很大一部分進行重新渲染。

在模型與視圖間進行同步

Angular包含了原生的數(shù)據(jù)綁定功能，與大廈多數(shù)其它客戶端框架所不同的是，它并不依賴于可觀察屬性，而是使用了臟檢查（dirty checking）方式。

皓眸哥

Angular的臟檢查方式有著以下一些優(yōu)點：

模型本身不會意識到它已經(jīng)成為一個被觀察的對象。
無需在可觀察屬性之間指定任何依賴。
函數(shù)同樣表現(xiàn)可觀察對象。
但這種方式也帶來了以下一些負面影響：

在與第三方組件或類庫集成的時候，你必須保證Angular能夠響應(yīng)它們對你的模型的任何改變。
在某些情況下會帶來性能方面的影響。

管理復雜的UI交互操作

如前文所述，控制器將負責實現(xiàn)UI元素的命令式邏輯。除此之外，還可以將控制器實現(xiàn)為一種主動控制顯示模式，以協(xié)調(diào)復雜的UI交互。

皓眸哥

管理狀態(tài)和路由

與Backbone類似，Angular自帶的路由器功能非?；A(chǔ)，并不適合于創(chuàng)建實際的應(yīng)用。令人欣慰的是，AngularUI Router項目填補了這一空白。它能夠管理應(yīng)用狀態(tài)、視圖，并且支持嵌套視圖。換句話說，它能夠滿足你對路由器的全部功能需求。當然，和Backbone的情況一樣，你并非只有這一種選擇，你也可以選擇其它的路由功能類庫（例如router.js）。

創(chuàng)建與連接組件

Angular包含了一個IoC容器，它與通常意義上的依賴注入方法非常相似，這就要求你必須編寫模塊化的代碼。這種方式能夠改善代碼的可重用性和可測試性，也使你免于編寫大量的樣板代碼。它的負面影響在于一方面增加了使用的復雜度，一方面削弱了對組件創(chuàng)建過程的可控程度。

總結(jié)

本文簡單地介紹了Backbone和Angular如何處理我們在創(chuàng)建web應(yīng)用時所遇到的各種問題。這兩個框架在某些問題的處理上使用了截然不同的方案，Backbone在顯示模板、創(chuàng)建數(shù)據(jù)綁定和連接組件方面給使用者更多的選擇。與之相反，Angular為這些問題提供了規(guī)定的方案，不過在創(chuàng)建模型與控制器方面的限制就比較少一些。