《茶餘飯後小故事》MV*、MVC、MVP、MVVM的前世此生

今天咱們講講歷史，講講故事，不扯高深術語。

MV*表示的意思是：M(Model邏輯層) + View(視圖層) + *（中間者）。上帝提出了這個邏輯與視圖分離，用中間者進行鏈接的偉大思想，並將實現這個思想的艱鉅任務安排給人間。

人們紛紛躍躍欲試，想率先實現上帝佈置的任務。隨着歷史的推移，不一樣時期前後出現了三個著名的中間者，他們依次是Controler、Presenter、ViewModel。

Controler是第一個吃螃蟹的小夥子，暱稱叫控制者。它與MV結合並自命名爲MVC模式。它平生最大的貢獻是能把視圖層View的數據寫進邏輯層Model,可是很惋惜，View不是經過它來讀取Model的數據，而是跳過它，直接讀取Model的數據。被「選擇性無視」的Controler大失顏面，這件事也讓它常常被後世取笑。

 

 

上帝很讚揚Controler的勇氣，但看着MVC這上下都不對稱的數據讀寫方式，感受有些啼笑皆非，顯然對Controler不是很滿意。

另一個叫Presenter的小夥站了出來，他身材健碩，力大無窮。只見他挺身而出地說：「我是Presenter,中文名叫主持人，之後視圖層和邏輯層他們之間的通訊交給我來主持！」。

因而一個新的模式出現了---MVP模式。

 

這個模式看起來很是不錯，在試行了一段時間後，上帝也感受很是滿意，它不只對稱，還隔離了Model和View，與前輩Controler那種半中間者不一樣，Presenter是一個真正意義上徹底體的中間者！

但使人沒有想到的是，好景不長，一段時間後Presenter忽然暴斃，死因：過分勞累。

人們開始反思MVP模式存在的問題，雖然它隔離了Model和View，可是Presenter老是須要手動去幫助Model和View完成通訊，是個「手動擋」，時間一長，Presenter裏面的業務邏輯愈來愈重，終於有一天它不堪重負倒下了。

還能再選一個Presenter嗎？顯然不能，如此繁重的須要手動完成的活兒，選上去了就是等死啊，太累了，沒人想幹。

不過江山代有人才出，人類的智慧真是無窮無盡，有一天一個看起來弱不由風的小姑娘站了出來，她說道：「我叫ViewModel，也許我能夠一試」。

民衆紛紛瞪大了雙眼，聯想到強壯如牛的Presenter都死得這麼慘，這個看起來弱不由風，身體幾乎透明的小女子，能承擔這樣繁重的任務嗎？

小女子說道：「我有三件法寶，分別喚做Angular，React和Vue，它們個個充滿魔力，不須要手動來回處理View和Model之間的那些瑣碎破事，它是自動完成的，用上它，大家甚至感受不到個人存在，我就是這麼6，大道至簡，一個真正完美的中間者可讓人幾乎忘卻它的存在。」

民衆一片譁然。

這，就是MVVM，它帶來了一個全新的理念：自動雙向綁定。

 

 

一時間，全民歡騰，上帝也大爲滿意，ViewModel的擁護者迅速增加，並迅速影響到全世界。

她是最好的中間者嗎？不知道，至少從目前來看，她是。