淺談表現與數據分離

#淺談表現與數據分離 ##表現與數據分離是什么 伴隨着一個程序的業務邏輯，會產生數據；數據從持久層抽出，經過一定邏輯，就會表現到程序界面上。一個程序在界面上的表現和保存下來的數據不應該是耦合的，數據應該可以對應多個表現界面。我們常說的表現與數據分離一般是指實現這個現象的技術，尤其是指一種代碼組織的方式。 ##常用方式 `MVC`是我們經常聽到的一種代碼組織方式，用於使表現與數據分離。傳統的MVC結合HTTP請求，把respone到瀏覽器的HTML全部算作為V。web2.0興起后，在HTML上也包含着較多的業務邏輯，於是前端的MVC也逐漸產生，並有`MVVM`等新的針對於前端的代碼組織方式及其他MV*框架。 ##回顧 之前我有談及到傳統MVC（以JavaEE的struts為例，見[這里](http://www.cnblogs.com/p2227/p/3551243.html))及我自己的在結合實現業務需求寫的一個[js模板](http://www.cnblogs.com/p2227/p/3546725.html) ##比較 ###傳統MVC struts這種傳統的MVC，思路很清晰：你發起一個HTTP請求，我根據請求的數據及持久層查到的數據（M）把相應的HTML（V）respone到瀏覽器上，處理這兩者關系的那一部分是控制器C，要拿出具體代碼來應該是配置的XML及相應處理這個抽象邏輯的類。 ###前端MVC `angular`、`backbone`等前端的MVC，大體上也差不多。當然前端的話可以用另外一種方式：你發起一個Ajax請求，服務端返回一堆JSON數據（M），再根據特定的規則（C）表現到HTML上（V）。這些框架一個重要的特點是擁有`路由（Router）`的概念，這是他們能稱為MVC框架的一個重要原因。 ###MVVM 以[`avalon`](http://rubylouvre.github.io/mvvm/)為例的MVVM框架，着力點在數據已經在前端之后，怎么樣更好的展現成HTML及維持與用戶的交互。前端MV*框架一般封裝的是數據與視圖的直接、雙向的綁定，基本操作都比較單一，數據怎么變，表現層就跟着怎么變，而沒有較復雜的邏輯關系。其實我們大多數的操作也就是需要一個簡單的雙向映射即可，業務的復雜我們應該細拆，用更加多的數據去描述，而不要把多個業務邏輯描述到一個數據（字段）上來。 ###jQuery 要對HTML操作就必然要用DOM。jQuery是操作DOM的首選js庫，但以上沒有一個MV*框架是基於jQuery的。我認為有三點原因 2. MV*框架針對單一的雙向操作，jQuery針對復雜的邏輯操作。我們沒必要去用一個龐大的Sizzle去選擇到我們要操作的節點，再進行操作。MV*框架宣揚的是一種清晰的前端數據與表現分離思路，數據應該是有計划有目的地通過界面表現的，而不是突發奇想忽然而來的一個操作。 1. jQuery不針對文本節點和注釋操作，看過源代碼可知，nodeType===3 || nodeType===8的節點被jQuery拋棄了，而這些都是MV*框架打着旗號能操作的，所以原生的DOM操作會更加適合MV*框架。 3. 體積、效率、代碼清晰度等其他方面的原因，你把jQuery引用起來，那jQ到底是屬於哪方面的職責？違背MV*框架的初衷了。 ###js模板 本人寫的[js模板](http://www.cnblogs.com/p2227/p/3546725.html)，實質上是一個單向的MVVM框架，只考慮到了M->V的轉換，其基本思路是：用數據分別去描述一段沒有業務邏輯HTML模板和一些分散的業務邏輯，再用一段通用的邏輯代碼去把它們組合在一起，形成HTML展現到界面上。缺少像avalon那樣的scan方式，所以是做不到V->M的即時反饋的。 ##深入思考MV* MV*框架一般都定義好自己的掃描范圍。像angular的ng-app、avalon主要是在scan的參數上。遍歷DOM樹尋找要綁定的數據及要展現數據的地方，否則白白浪費效率。 除了單一的雙向數據綁定，MV*框架還會定義幾種稍微復雜的數據表現約定。像 針對數組、針對函數、針對表格等，本質上還是制定一種約定：**數據只要按照這種方式去放置，我的框架就有一種內置的現成的表現形式，你就不用再去關注里面的業務邏輯了。**框架就是把各位碼農每天重復寫來寫去而技術含量不高的操作（像CRUD）給抽象出來，幫我們從繁重的重復業務中解放出來，而更加關注一些核心的、較復雜的業務邏輯。 框架一般會給出一套事件綁定機制，讓你去用它的事件。當然了，我們在input框中輸入，那邊的數據就立馬改變，靠的必然是事件，如果用了這些框架還去自己定義事件，容易產生一些未知的錯誤。 引用[一篇國外的博文](http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/)，里面有提及到MVC的好處 * 易於維護 * 便於單元測試 * 剔除一些重復、低層的代碼 * 分離了程序邏輯與表現界面，使得負責這兩塊的人可以同時工作 ##總結 再回到文章的標題，表現與數據分離是我們的目的，MVC、MVP還是MVVM，都只是一種手段。每一種語言每一個框架有其實現的具體細節。但總的思想就是：如何更好地組織代碼，解決表現與數據分離的問題。如果不這么組織，后果可想而知：當需求變化時，我們無法估計要修改多少處代碼，也無法估計修改后會產生多少的BUG，因為很多東西耦合在一起了，牽一發而動全身。我們也不一定要限制於這些代碼約定好的組織方式，畢竟是開源的，可以根據自己當前的項目產品實質需求進行改造。我們也不能太依賴於框架，要看到低層的實現，對於開源軟件也很容易處理。 ##參考 http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/ http://www.dotblogs.com.tw/regionbbs/archive/2011/09/29/compare.to.mvp.mvc.mvvm.aspx