MVC MVP MVVM

MVC

 　　比我還大的東西都不會太難,好比mvc,mvc的區分方式很是好理解,或許他也僅僅只是一個分層方式....從對象或者說組件的角度來看,屬性,方法和事件三者是必須的,那麼將其分爲一種設計分層來講應該就是mvc

M

　　軟件,產品,對象,不管什麼離不開內容,就算是一個雜亂無章的一斷字節,也須要將其進行整理,返回的結果就稱之爲M,大多數狀況下,M來自數據庫

C

　　面向對象的方式,少不了事件的建立,固然就算是面向過程也會有事件的產生,事件,具體的方法,邏輯,他可能對模型有影響,也可能對展現有影響,在面向對象中,她可能會依賴屬性,無論怎樣,業務邏輯的體現,在這裏

V

　　視圖,儘管稱之爲視圖,我仍是將它理解爲監控,互動,負責捕捉頁面與人的交互行爲(固然渲染和監控都是視圖的責任,我只是調換了一下順序),在V中將會產生各類不可控,不穩定的事件(你沒法知道什麼時候,何地甚至前後順序),他們會出發你C中定義的方法

溝通

　　固然三者間的溝通規則,通常會要求使用萬金油的接口,大多數狀況下會選擇實現(看一下你寫的winform或者swing)

 

　　MVC僅僅製做了總體的劃分規則,更詳細的並無太多的幫助,以致於如今當咱們建立一個web,swing,winform工程時,已是MVC了,相對於曾經的model1時代,只要你在數據庫分離,提取出模型,也能成爲MVC,更細緻的規則必須須要具體分析,畢竟context is everything

MVP

　 沒有用過MVP之類的框架,但這不影響我去胡扯- -

p與c

　　依然將M理解爲屬性,其實對屬性的處理,通常都是引用式的處理,你能夠擁有它,建立他,修改它,但你不能刪除他,好比

　　你能夠獲取對象A,你的確可讓屬性a制空,可是你不能刪除對象A...固然刪除程序中的一個對象,這是垃圾回收器的事,個人意思是若是這是邏輯上的對象呢?

若是真的在控制器中緩存了A,模型的刪除將會形成邏輯上的錯誤,處理的方式很簡單,面向接口,不在擁有模型A的引用,所有交給M(這不是P要解決的),換到另外一邊看(C與V),在展現中,展現的效果會隨意進行修改的,好比常用的.tofixed,format甚至render(你還能夠想的更大一些),問題在於這些展現數據的變動是否須要由V來進行更改?P的概念就在這裏,V不須要且不能去修改M,他須要的僅僅是展現

栗子

　　我將這種處理方式,理解爲MVP,V絕壁不去管你你來的是什麼,反正我就是將你展現出來就是了,UI線程所須要作的就是展現和互動

MVVM

　　綁定是關鍵,雖稱之爲下降依賴,V與VM絕壁是僅僅依賴在一塊兒的,從cs端的程序來看很是好理解,但誰讓我是搞web的類

VM

　　有一個很火的詞,先後端分離,專門用來吐槽上面的一種作法,他們認爲,後端不須要去搞顯示邏輯,換句換說,V與C都是前端的。。。說的好像有點高深,若是你用過easyui,ext或者其餘組件,其實你就已經先後端分離了

使用各類組件,必需要一個json對象,然後經過這個json對象,產生dom,產生了展現效果,他有點像jsp,不過在運行的時候一個在後端,一個在js中,若是你使用了他們,而且被告知本身的系統是MVC,是否會認爲,在這種狀況下,這個C壓根什麼都沒幹嗎,service和dao徹底就是一個東西,沒錯,你被忽悠了,你的C在前端,大家已經先後端分離了

　　有且只有VC在一塊兒才能使用VVM

　　想象一下easyui,或者咱們平時建立的組件,經過接口(選擇器)去選擇dom節點,然後爲他賦值,併爲他設置方法和屬性,既然VC已經在一塊兒了,爲何還要經過接口(選擇器)去尋找呢?這裏的依賴應該是容許的吧...看個easyui的方式

這是一個前端面向接口規範(面向選擇器)的作法,看起來沒有什麼問題,若是你用過你就會發現,難以維護,由於最終展現的效果跟你寫的原形根本不同,爲了尋找id="cc"的具體實現,你須要找到那個js,並找到他的實現,他並不想jsp/asp那樣,能夠簡單的進行猜想,那若是是這種方式呢?

至少,你不須要再去點擊js而後查看實現了吧...這就是一種VVM的實現,發現沒,VVM之間能夠超級依賴的,不是全部js都能識別data-options是什麼的,他可不是一個規範,一個接口

vvm所作的就是自動查詢節點的功能,由於你已經寫在他臉上了,它的關鍵就是常說的綁定

　　固然easyui可不是一個標準的前端MVVM,只是核心點,有那麼點意思- -就像大多數前端要求先後端分離,使用easyui,ext的小做坊的程序猿可真感覺不要到他們的優點

　　很顯然前端MVVM能夠幫助咱們去梳理業務邏輯結構,若是要是用他們的話,瞭解一下原理,也是必須的