最近前端圈子裡面，發現大家都在熱炒概念，什麼knockout，angularJs，都被捧成神了，鄙人不才，最近心情也不好，特地寫這篇文章來找罵

寫程式碼的碼農都知道，Java社群雖然不是一個提出分層思想的，確實貫徹的最好的，如今是個Java開發都不會不知道SSH的開發模式，從MVC到MVVM的概念的熱炒，其實真沒什麼技術進步

先看什麼是MVVM

View一般就是我們平常說的HTML文字的Js模板，裡面可以嵌入一些js模板的程式碼，比如Mustache，比如jstl類似的模板虛擬碼

ViewModule層裡面就是我們對於這個檢視區域的一切js可視業務邏輯，舉個例子，比如圖片走馬燈特效，比如表單按鈕點選提交，這些自定義事件的註冊和處理邏輯都寫在ViewModule裡面了

Module就更簡單了，就是對於純資料的處理，比如增刪改查，與後臺CGI做互動

那麼什麼是MVVM框架呢？？一般他們都是這麼做的

1.  定義一串所謂的偽模板程式碼，例如通過className標註，或者自定義tag的方式，將一段html文字區域給標註宣告起來，意思就是喊一嗓子，“喂，兄弟們，這塊地方我佔了，要拉屎去別處拉去”

2.  通過類似jstl之類lamda表示式，來做js模板，“拜託夥計，天堂有路你不走，非要自己搞一套，你就不能暴露介面讓大家用自己的模板語言，比如Mustache或者jtpl嗎？”

3.  很傻比的封裝一串自己的所謂資料模組元件，與不同型別的資料來源做資料傳輸和適配，一般都不會分層很清晰，加入後臺資料欄位改了，寫框架的都沒腦子的，從來不做資料欄位的自定義適配（舉個例子，原來後臺傳遞的欄位是person.userName，現在改成了小寫，person.username，你就傻逼的去吧模板再改一下吧，其實要解決這個問題，非常簡單，在MVVM層中引入一層DO，領域物件層，Module到DO之間還有一層轉換就可以搞定這個問題）

4.  非不暴露自己的自定義事件模型，就是那個觀察者模式啦，自己亂七八招在頁面上繫結一堆form change之類的事件，以實現View與Module的單向繫結

5.  所謂的雙向繫結，也就是OOP語言中早被爛透了的getter，setter模型，ES5+可以用defineProperty，低版本就需要自己在js object賦值的時間做寫死程式碼方式的處理了

我們再來看細節

1. 雙向繫結

號稱是最難理解的地方，其實是框架的作者根本就沒理解Java社群對於軟體開發分層理解的精髓

標準的資料驅動開發，應該如上圖所示，在一個View的生命週期內，一個ViewModule會管理一個DomainObject（業務模型），一個DO可能包括多個Module資料模型，一個Module可能來自多個數據源，而不是想很多所謂的MVVM框架那樣強迫一個M來一個數據源

按照上圖標準分層方式來劃分的好處，在於，邏輯清晰，Module層粒度夠細，可以被多次複用

DO層與VM層View層屬於一一對應關係，方便對資料做增刪改查的同步

每一層應該是獨立的，非一定要使用MVVM框架的緊耦合，可以用自己使用不同的js外掛或者模組實現MVVM

我們拋棄框架，單純的看資料，其實我們要解決的問題很簡單

a) 當DO物件屬性放生變化時候，通知View更新

b) 當View上表單值放生變化時，通知DO更新，並非同步通知佇列同步到資料來源

先來看問題a，這個最簡單，DO是一個基本的Javascript Object，我們在View上的模板顯示是這個Object.property，

改變一個Object物件的方式無非幾種，一種是

a) 顯示Object.property = ‘我是傻逼’

b) xxxx.methodName(Object, ‘property’, ‘我是傻逼’)

c) xxxx.merge(Object, {‘property’: ‘我是傻逼’})

如果是a的情況，ES5+，可以通過設定Object.defefineProperty(‘property’,{set: functiono(){},get:function(){}})，來做賦值和取值的監控觸發

對於IE8一下，因為js不支援運算子過載，所以暫時沒有好的辦法，所以如果只考慮移動端的話，直接defineProperty就全部搞定，如果是要考慮PC的話，就不建議開發者使用直接賦值的方式，參考java的開發模式，也是推薦OOP時候，使用set方式賦值，而不是直接=賦值

當然了，如果你非要相容IE8一下的話，用定時器做輪訓，配合for in 反射，通過髒資料與原始備份對比的方法也是一種辦法，不過這種辦法在當前頁面非常耗效能，由於IE8一下不支援多執行緒，HTML5 worker，如果未來flash 外掛支援多執行緒的話，倒是可以用js和flash外掛做執行緒互動的方式做髒資料檢測

如果是b的情況，那就太簡單了，在methodName裡面觸發對於該屬性修改的回撥即可，如何註冊回撥呢，首先我們要實現一個類似Dom Event的自定義物件的Event模型，然後通過類似Dom Event的註冊事件方式，註冊觀察者，訂閱事件，當執行了methodName時候，傳送訊息，通知所有訂閱者執行回撥

如果是c的情況，類似b一樣處理

這樣一看，雙向資料繫結的問題就非常簡單的解決了

我們再來看另外一個MVVM的問題，非簡單資料模型，複合資料模型（DO的屬性值不是一個string，而是一個Object，且這個Object可能還巢狀多層Obejct的時候）的處理辦法，這個一般的MVVM框架直接不考慮，或者通過長欄位名的方式繞過這個問題

這個問題是這樣的，早在10幾年前，java structs框架流行的時候就出現了，當一個表單，出現需要對兩個Java Bean做update操作時候，一個bean是user，一個bean是成績

對應的表單欄位名，就是 user表.name，user表.id，score表.point，

在struct2裡面，處理邏輯是把 “點”作為特殊符號，在做form序列化時候，非包含點的欄位的值都是string，包含點的欄位是一個Object，比如剛才的form序列化之後結果就是 { user: {id :’’ , name: ‘’}, score: {id: ‘’, point: ‘’}}

同理在MVVM實現時，也是一樣，認為點是分割物件的關鍵字，這樣我們就可以實現把多個物件巢狀到View模板裡面，實現複合Object的雙向對映

最後一個問題，也就是高階MVVM程式設計裡面必須要面對的問題，就是自定義事件的廣播和冒泡，我看過大多數的MVVM框架，對於廣播，這塊有部分實現了，但是對於冒泡一個都沒實現

其實這個真的不是很複雜的問題，事件廣播，這個最簡單，三歲小孩都能寫，我們在註冊回撥時候，不是有一個事件佇列嗎，在回撥時候，通過特殊標記位，控制是否繼續擴散廣播，還是執行完畢終止即可

而自定義事件的冒泡要騷騷複雜一些，他是由於OOP程式設計裡面的繼承和包含關係引申而來的，我們先說包含關係，前面說了MVVM框架裡面，都會宣告一塊地方為VM控制區域，一般垃圾的框架都不會考慮，VM巢狀的情況，因為圖簡單嗎

但是實際開發過程中，你會遇到很多這種情況，就是VM複用的問題，一般都是發現使用了MVVM框架之後，發現VM定義的太大，沒法複用，如果要複用VM就又發現VM定義的太小，出現需要VM巢狀的情況沒法用

其實簡單，我們知道DOM事件是有冒泡的，VM同理，只要在自定義事件模型裡面定義了VM的父子關係，或者同級關聯關係，即可實現VM的自定義事件的廣播和冒泡，另外也解決了VM複用的問題，可以讓程式碼顆粒度更小

另外那種，宣告式程式設計這種老掉牙的概念就真的別在吵了，還記得10幾年前的structs的tag嗎，js圈子裡面這種通過自定義tag，自定義className，自定義屬性，掛載js來自定識別執行邏輯的例子大把皆是，還是建議廣大前端開發，不要浮躁，多像java社群學習，多多從根本上了解分層理念的精髓，不要聽了吹牛逼，聽風就是雨，還是多瞭解原理才是真理啊

最近心情很不好，股票大跌，公司的事情你懂的，寫這篇文件純屬沒事找事，歡迎廣大道友開罵，來陪我大戰三百回合