JavaScript客戶端MVC框架用法

導語：JavaScript客戶端MVC框架用法你會嗎？下面的是本站小編為大家蒐集的JavaScript客戶端MVC框架用法，供大家參考。

15 年前，許多人都使用 Perl 和 ColdFusion 之類的工具構建網站。我們經常編寫可以在頁面頂部查詢資料庫的指令碼，對資料應用必要的轉換，以及在同一個指令碼底部顯示資料。這類架構適合於向網站新增簡單 的 “Contact us” 表單。然而，隨著應用程式變得更加複雜，這種方法無法進行相應的擴充套件來處理更大的複雜問題。大部分 Web 應用程式現在已經對模型-檢視-控制器 (MVC) 架構進行了標準化，使用單獨的程式碼實現業務邏輯、顯示邏輯和使用者互動（路由）邏輯。湧現出從 Spring MVC 到 Rails 的各種框架可以幫助您快速實現基於 MVC 的 Web 應用程式。

JavaScript客戶端MVC框架 詳解不同框架用法 三聯

幾年前，jQuery 是用於構建客戶端 JavaScript 應用程式的主流庫。然而，隨著應用程式中的 JavaScript 的複雜性日益增加，jQuery 成為一項處理複雜性的必要不充分技術。例如，用於待辦事項 (to-do) 列表的單頁面應用程式可以包含一個緊急待辦事項列表、一個完整的待辦事項列表、一個當日待辦事項列表，以及一個過期待辦事項列表。在刪除某個待辦事項時會 怎樣？如果任務很緊急但已過期，您可能需要手動編寫程式碼來從檢視中的三個或四個不同位置中刪除該事項。如果刪除某個物件後需要您刪除或更改螢幕上顯示的其 他相關物件，這樣複雜性就會變得無法控制。

客戶端 MVC 框架旨在解決此類問題，並且大多數框架都表現出色。但是您如何從許多 JavaScript 客戶端 MVC 框架中選擇合適的框架。本文將從較高的層面簡要介紹其中一些最流行的框架。以及如何針對給定的用例選擇合適的框架。

在使用率方面，Backbone 是目前為止最流行的客戶端 MVC 框架。它被廣泛應用於各個開發社群，Rails 開發人員對它的採用率一直較高，並出現了許多廣受歡迎的資源，比如 thoughtbot（一家備受尊敬的 Rails 諮詢公司）推出了 Backbone on Rails（參見 參考資料）。 的優勢在於它與具象狀態傳輸 Web 服務實現了良好的整合。如果您對後端資料使用 RESTful JavaScript Object Notation (JSON) 模型並遵循 Backbone 所期望的約定（與 Rails 中的約定匹配），那麼您不需要編寫任何程式碼就可以將 Backbone 連線到伺服器，從而節省大量的時間。

在 Backbone 中，應用程式包含集合（使用者或文章）、模型（單個使用者或文章）、檢視和路由器。 中的檢視是非預定的 (nonprescriptive)，允許您使用自己喜歡的 JavaScript 模板或框架。路由器結合了 Rail 風格的路由器和一個傳統的' MVC 控制器，負責獲得給定的 URL 並通知框架要執行的程式碼。清單 1 中的 路由器程式碼給出了一個示例。

　　清單 1. 樣例 路由器程式碼

var Workspace = nd（{

routes： {

“help”： “help”, // #help “search/：query”： “search”, // #search/kiwis “search/：query/p:page”： “search” // #search/kiwis/p7 },

help： function（） {

....

},

search： function（query， page） {

.....

}

}）;

附帶了一個 副本。 是一組實用工具，可以通過更加功能化的方式簡化 JavaScript 的編寫，並支援一系列有用的基於集合的操作。它還包括 ory，後者可以幫助您巧妙地處理頁面導航。

主要優勢在於它與伺服器的自動整合。如果這樣做適合您的用例，那麼學習如何使用 將是值得的。您可以通過一些框架在一兩個小時之內初步掌握可能需要花一到兩天學習的 基礎知識。這非常適合比較大的專案，這類專案至少持續幾周的時間。

仍然算不上一種完好的解決方案。您可能需要編寫相當數量的程式碼來處理潛在的記憶體洩露等問題。您還可能需要試驗幾種方法來檢視呈現內容，之後才能找到真正滿足需求的方法。

通常與 進行比較；它受到 的影響，並在使用率方面與前者接近。 包含類、模型、控制器和檢視，這比 引入的集合更加傳統一些。

使用 CoffeeScript（參見 參考資料）編寫，這使它更加簡練且（依我看來）更易於讀取原始碼。要了解 如何工作，您需要熟悉 CoffeeScript。然而，您不必使用 CoffeeScript 構建 應用程式。但是，如果已使用 CoffeeScript 進行了構建，您可以訪問 CoffeeScript 特性（如類）。CoffeeScript 使用原型繼承而非經典繼承，因而無法支援在本地 JavaScript 中的類。CoffeeScript 使用了一些非常標準的模式，為希望使用它們的開發人員提供類。如果使用純 JavaScript 編寫 應用程式，您只需使用 ，後者使您不需要編寫 CoffeeScript 程式碼就可以訪問類。

中的模型、控制器和檢視都使用類實現，因此可以同時編寫類和例項方法。模型負責處理業務邏輯，屬於模組類，您可以擴充套件幷包括其他模組，從而混合重用屬性和 功能。模型可以自動序列化到 JSON 中，通過僅使用本地儲存實現持久化。或者可以使用 Asynchronous JavaScript + XML (Ajax) 將物件持久化到伺服器中。和 一樣， 現在提供了合理的預設設定，可以通過 Ajax 實現持久化，但是仍可以在必要時編寫自己的特定實現，並且非常簡單。清單 2 展示了來自一個 應用程式中的 CoffeeScript 程式碼的示例。

　　清單 2. 應用程式中的 CoffeeScript

class Contact extends l

@configure “Contact”, “first_name”, “last_name”

@filter: （query） ->

@select （c） ->

t_xOf（query） is not -1

fullName: -> ［@first_name， @last_name］（‘ ’）

和 兩者之間最主要區別是它們處理伺服器互動的方式。 在顯示響應之前將等待伺服器響應。如果試圖刪除、插入或更新某個元素，使用者介面 (UI) 直到操作成功完成才會重新整理。而 側重於即時更新 UI，而且在進行後臺處理時處理 Ajax 伺服器。這種更新是一種非常重要的實踐，也是在這兩種優化的擁有良好編檔的流行框架之間選擇時需要考慮的的主要因素。

如果您的目標是建立一種客戶端體驗，而對伺服器狀態的更新是次要的，那麼 可能是一種更好的選擇。如果仍然使用伺服器來檢查狀態變化的有效性則 可能更適合。 提供了響應性更好的 UI。但是，如果顯示成功刪除某個元素，只是讓伺服器傳送一個響應，不允許您刪除該項，因為該項正在被其他人使用，那麼會發生什麼？針對這個問題存在一些 應急方案，但是通常來講 更加適合使用者操作自有（而非共享）資料。 的一個常見用例就是購物車，其中所有驗證都可以在客戶端處理。

　　Knockout

人們可能會爭論目前為止討論的這些工具是否是原本意義上的真正的 MVC 框架。Knockout 明確實現了模型-檢視-檢視-模型 (MVVM)，而不是經典的 MVC。但是，不要因此而妨礙到您的決策制定。在選擇框架時，更重要的是檢視所提供的功能而非首字母縮略詞或分類。

在熟悉 MVVM 模型的 Microsoft 開發人員之間特別受歡迎。對於主要問題是將模型狀態通過宣告的方式繫結到檢視用例， 是非常好的選擇。 對於前面提到的示例待辦事項應用程式是非常理想的選擇，該應用程式的主待辦事項列表的子集都有自己的檢視，在刪除某個待辦事項後需要更新所有的列表。

在 中，您將建立模型、檢視模型和檢視。與在 和 中一樣，負責處理業務邏輯、驗證和與遠端伺服器互動的 Ajax（假設您不僅僅是建立一個本地應用程式）。檢視模型程式碼負責保留和操作模型資料。例如一個檢視模型可能包含新增、編輯以及從列表中刪除內容項的方 法。檢視模型非常貼近於傳統的 MVC 架構中的控制器。檢視就是一些模板，包含將資訊呈現到螢幕的標記。在 中，這些可以通過宣告的方式繫結到檢視模型（方便入門）。一些學員可以在一個小時內掌握並使用 Knockout，並可在三個小時內構建非凡 (non-trivial) 應用程式。

一般來講， 比較適合較小、較簡單的專案。人們往往將 或 用於更大、更復雜的專案。也就是說，有經驗的 開發人員可以建立非常複雜、同時又易於維護的應用程式。如果考慮使用 ，您也應當考慮 和 （參見 參考資料），後兩者是兩種相對輕量級、易於啟動的框架。

是一種有趣的新框架，由 JSConf 在 2011 年推出，但是又經過了幾個月的時間才能夠通過下載獲取。 已經開始受到一些喜歡並得到開發 MVC 應用程式的程式設計師的關注。表面上看，Batman 在易於入門、支援檢視宣告繫結方面與 類似。 提供了一些其他功能，包括可選的全棧 (full-stack) 框架，用於自動程式碼生成器、構建工具甚至後端 伺服器程式碼，可以實現您的伺服器端 API。

和 一樣， 也使用檢視繫結。清單 3展示了一些樣例檢視程式碼。

　　清單 3. 中的檢視程式碼示例

<ul id=“items">

<li data-foreach-todo=“” data-mixin=“animation”>

<input type=“checkbox” data-bind=“ne” data-event-change=“” />

<label data-bind=“” data-addclass-done=“ne”

data-mixin=“editable”></label>

<a data-event-click=“roy">delete</a>

</li>

<li><span data-bind=“th”></span>

<span data-bind=“‘item’ | pluralize th”></span></li>

</ul>

清單 3中的程式碼是有效的 HTML5，包含一些額外的屬性，供 Batman 繫結資料和事件。在 中，您的應用程式包含模型、檢視和控制器。模型支援驗證功能，能夠實現生命週期事件，包括一個內建的恆等對映 (identity map)，並且可以被告知（主動記錄樣式）如何堅持使用 、Storage、sStorage 或自定實現。檢視為一些 JavaScript 類，呈現用純 HTML 編寫的模板，還有一些用 data-* 屬性繫結模型資料並觸發事件處理器的構件。控制器為一些永久物件，處理來自檢視的事件，訪問模型資料，並呈現相應的檢視。

　　選擇一種 JavaScript 框架

如果您正在從事一個長期的大專案，那麼瞭解 或 很有必要，因為它們獲得了廣泛的採用，可以解決您可能遇到的問題。然而，即使有了這些專案，您要明白您不是有必要使用一個成熟的伺服器端 MVC 框架，而是還需繼續編寫基礎架構程式碼。

嘗試使用在檢視中用了宣告式繫結的框架將非常有必要。此類框架具有與 之類的專案不同的優缺點。如果考慮使用宣告式檢視繫結，那麼花些時間研究一下更新的 框架提供的額外功能。雖然 不像其他框架那麼流行，但它正在快速發展，而且提供了比普通客戶端 MVC 框架更豐富的特性。

在不同框架中進行原型化，感受一下這些框架的用法，這樣做非常有必要。特別是對於客戶端 MVC 框架來說，原型化是從不同選項中進行選擇的最快速、最有效的方法之一。一種方法是讓每個團隊成員花一到兩天的時間，使用不同的框架進行原型化，然後進行回 顧並討論結果。最壞的情況是，如果您還有一對框架需要從中進行選擇，那麼再額外花一天左右的時間構建二者的概念，直到選出最適合您的用例的框架。

考慮靈活性。仔細考慮您可以做哪些工作來降低對框架的依賴性，這對於許多框架來說是一個艱鉅的任務。為將來 12 到 18 個月內遷移到另一個框架制定一個備份方案，以防您發現需求和所選的框架沒有按照預期進行。

　　結束語

JavaScript 客戶端 MVC 框架仍然不夠成熟。這個領域正在發生快速改變，缺少一致認可的最佳實踐。對於較大的專案 和 都是非常流行、具有良好支援的。如果傾向於宣告檢視繫結，那麼 和 則都是不錯的選擇。