技術趨勢:是什麼讓MVC悄然消失的?

技術趨勢:是什麼讓MVC悄然消失的?

投身IT江湖,就像打王者榮耀一樣,好不容易練會了一個硬性,結果天美把它削弱了,你不得不再去練習一個。

MVC這門技術伴隨著我的成長,感情和Java一樣深厚,但是,最近兩年卻不得不和MVC說再見了。是的,不是Struts沒了,也不是SpringMVC沒了,而是MVC這種架構模式被淘汰了。當時代拋棄你時,連一聲再見都不會說。所以,看到這篇文章的各位程序員兄弟們,緊跟技術發展趨勢,再牛逼一點的,能夠提前預見技術趨勢,提前準備,最牛逼的,引領技術趨勢,咳咳,想的有點多。

我們先回顧一下MVC吧,就像懷念一個老朋友。

MVC模式(Model–view–controller)是軟件工程中的一種軟件架構模式,把軟件系統分為三個基本部分:模型(Model)、視圖(View)和控制器(Controller)。( 摘自 維基百科-MVC )

  • 模型(Model) 用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。“ Model ”有對數據直接訪問的權力,“Model”不依賴“View”和“Controller”,Model 不關心它會被如何顯示或是如何被操作。但是 Model 中數據的變化一般會通過一種刷新機制被公佈。為了實現這種機制,那些用於監視此 Model 的 View 必須事先在此 Model 上註冊,從而,View 可以瞭解在數據 Model 上發生的改變。
  • 視圖(View) 能夠實現數據有目的的顯示。在 View 中一般沒有程序上的邏輯。為了實現 View 上的刷新功能,View 需要訪問它監視的數據模型(Model),因此應該事先在被它監視的數據那裡註冊。
  • 控制器(Controller) 起到不同層面間的組織作用,用於控制應用程序的流程。它處理事件並作出響應。“事件”包括用戶的行為和數據 Model 上的改變。

Struts和SpringMVC曾經是MVC雙雄。

那是什麼導致MVC模式被淘汰了呢?移動時代的到來,展示端愈來愈重要,所以前端技術發展越來越猛烈,前端工程師也不再是團隊的小弟了,他們要求和Java工程師平等對話。

前後端分離來了,Node.js來了,前端工程師把MVC的職責都給搶走了,後端工程師真正成為了後端,只需要提供API給前端就行,再也不用關心redirect\\forward有什麼區別,再也不用關心session、cookies有什麼區別,怎麼樣。當前端工程師拿走MVC的職責之後,自然會把MVC模式改成更適合前端的模式:MVVM。

MVVM(Model–View–Viewmodel)也是一種軟件架構模式,它必將取代MVC,或者說的好聽一些,它是MVC基礎上演化而來。

MVC中的M就是單純的從網絡獲取回來的數據模型,V指的我們的視圖界面,而C就是我們的ViewController。

在其中,ViewController負責View和Model之間調度,View發生交互事件會通過target-action或者delegate方式回調給ViewController,與此同時ViewController還要承擔把Model通過KVO、Notification方式傳來的數據傳輸給View用於展示的責任。隨著業務越來越複雜,視圖交互越複雜,導致Controller越來越臃腫,負重前行。髒活累活都它幹了,到頭來還一點不討好。福報修多了的結果就是,不行了就重構你,重構不了就換掉你。

來一張斯坦福老頭經典的MVC架構圖。

技術趨勢:是什麼讓MVC悄然消失的?

所以為了解決這個問題,MVVM就閃亮登場了。他把View和Contrller都放在了View層(相當於把Controller一部分邏輯抽離了出來),Model層依然是服務端返回的數據模型。而ViewModel充當了一個UI適配器的角色,也就是說View中每個UI元素都應該在ViewModel找到與之對應的屬性。除此之外,從Controller抽離出來的與UI有關的邏輯都放在了ViewModel中,這樣就減輕了Controller的負擔。

技術趨勢:是什麼讓MVC悄然消失的?

這張圖是從網上找的,MVVM還在學習階段,後續補一張自己的

從以上的架構圖中,我們可以很清晰的梳理出各自的分工。

  • View層:視圖展示。包含UIView以及UIViewController,View層是可以持有ViewModel的。
  • ViewModel層:視圖適配器。暴露屬性與View元素顯示內容或者元素狀態一一對應。一般情況下ViewModel暴露的屬性建議是readOnly的,至於為什麼,我們在實戰中會去解釋。還有一點,ViewModel層是可以持有Model的。
  • Model層:數據模型與持久化抽象模型。數據模型很好理解,就是從服務器拉回來的JSON數據。而持久化抽象模型暫時放在Model層,是因為MVVM誕生之初就沒有對這塊進行很細緻的描述。按照經驗,我們通常把數據庫、文件操作封裝成Model,並對外提供操作接口。(有些公司把數據存取操作單拎出來一層,稱之為DataAdapter層,所以在業內會有很多MVVM的變種,但其本質上都是MVVM)。
  • Binder:MVVM的靈魂。可惜在MVVM這幾個英文單詞中並沒有它的一席之地,它的最主要作用是在View和ViewModel之間做了雙向數據綁定。如果MVVM沒有Binder,那麼它與MVC的差異不是很大。

總結來說,MVC模式本來是完美的,但是隨著移動時代的到來,前端數據展示、交互、跳轉變得複雜了,Controller的只能真的不適合在放到後端了,所以MVVM就出現了。

後面的文章中會繼續闡述MVVM、SPA等前端的架構模型,就像練一個天美的新英雄一樣。


分享到:


相關文章: