建站
咨詢
售后
建站咨詢
新聞中心
投身IT江湖，就像打王者榮耀一樣，好不容易練會(huì)了一個(gè)硬性，結(jié)果天美把它削弱了，你不得不再去練習(xí)一個(gè)。
MVC這門技術(shù)伴隨著我的成長，感情和Java一樣深厚，但是，最近兩年卻不得不和MVC說再見了。是的，不是Struts沒了，也不是SpringMVC沒了，而是MVC這種架構(gòu)模式被淘汰了。當(dāng)時(shí)代拋棄你時(shí)，連一聲再見都不會(huì)說。所以，看到這篇文章的各位程序員兄弟們，緊跟技術(shù)發(fā)展趨勢(shì)，再牛逼一點(diǎn)的，能夠提前預(yù)見技術(shù)趨勢(shì)，提前準(zhǔn)備，最牛逼的，引領(lǐng)技術(shù)趨勢(shì)，咳咳，想的有點(diǎn)多。
我們先回顧一下MVC吧，就像懷念一個(gè)老朋友。
MVC模式(Model–view–controller)是軟件工程中的一種軟件架構(gòu)模式，把軟件系統(tǒng)分為三個(gè)基本部分：模型(Model)、視圖(View)和控制器(Controller)。( 摘自 維基百科-MVC )
模型(Model) 用于封裝與應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)以及對(duì)數(shù)據(jù)的處理方法?！?Model ”有對(duì)數(shù)據(jù)直接訪問的權(quán)力，“Model”不依賴“View”和“Controller”，Model 不關(guān)心它會(huì)被如何顯示或是如何被操作。但是 Model 中數(shù)據(jù)的變化一般會(huì)通過一種刷新機(jī)制被公布。為了實(shí)現(xiàn)這種機(jī)制，那些用于監(jiān)視此 Model 的 View 必須事先在此 Model 上注冊(cè)，從而，View 可以了解在數(shù)據(jù) Model 上發(fā)生的改變。
視圖(View) 能夠?qū)崿F(xiàn)數(shù)據(jù)有目的的顯示。在 View 中一般沒有程序上的邏輯。為了實(shí)現(xiàn) View 上的刷新功能，View 需要訪問它監(jiān)視的數(shù)據(jù)模型(Model)，因此應(yīng)該事先在被它監(jiān)視的數(shù)據(jù)那里注冊(cè)。
控制器(Controller) 起到不同層面間的組織作用，用于控制應(yīng)用程序的流程。它處理事件并作出響應(yīng)?！笆录卑ㄓ脩舻男袨楹蛿?shù)據(jù) Model 上的改變。
Struts和SpringMVC曾經(jīng)是MVC雙雄。
那是什么導(dǎo)致MVC模式被淘汰了呢?移動(dòng)時(shí)代的到來，展示端愈來愈重要，所以前端技術(shù)發(fā)展越來越猛烈，前端工程師也不再是團(tuán)隊(duì)的小弟了，他們要求和Java工程師平等對(duì)話。
前后端分離來了，Node.js來了，前端工程師把MVC的職責(zé)都給搶走了，后端工程師真正成為了后端，只需要提供API給前端就行，再也不用關(guān)心redirect\forward有什么區(qū)別，再也不用關(guān)心session、cookies有什么區(qū)別，怎么樣。當(dāng)前端工程師拿走M(jìn)VC的職責(zé)之后，自然會(huì)把MVC模式改成更適合前端的模式：MVVM。
MVVM(Model–View–Viewmodel)也是一種軟件架構(gòu)模式，它必將取代MVC，或者說的好聽一些，它是MVC基礎(chǔ)上演化而來。
MVC中的M就是單純的從網(wǎng)絡(luò)獲取回來的數(shù)據(jù)模型，V指的我們的視圖界面，而C就是我們的ViewController。
在其中，ViewController負(fù)責(zé)View和Model之間調(diào)度，View發(fā)生交互事件會(huì)通過target-action或者delegate方式回調(diào)給ViewController，與此同時(shí)ViewController還要承擔(dān)把Model通過KVO、Notification方式傳來的數(shù)據(jù)傳輸給View用于展示的責(zé)任。隨著業(yè)務(wù)越來越復(fù)雜，視圖交互越復(fù)雜，導(dǎo)致Controller越來越臃腫，負(fù)重前行。臟活累活都它干了，到頭來還一點(diǎn)不討好。福報(bào)修多了的結(jié)果就是，不行了就重構(gòu)你，重構(gòu)不了就換掉你。
來一張斯坦福老頭經(jīng)典的MVC架構(gòu)圖。
所以為了解決這個(gè)問題，MVVM就閃亮登場(chǎng)了。他把View和Contrller都放在了View層(相當(dāng)于把Controller一部分邏輯抽離了出來)，Model層依然是服務(wù)端返回的數(shù)據(jù)模型。而ViewModel充當(dāng)了一個(gè)UI適配器的角色，也就是說View中每個(gè)UI元素都應(yīng)該在ViewModel找到與之對(duì)應(yīng)的屬性。除此之外，從Controller抽離出來的與UI有關(guān)的邏輯都放在了ViewModel中，這樣就減輕了Controller的負(fù)擔(dān)。
這張圖是從網(wǎng)上找的，MVVM還在學(xué)習(xí)階段，后續(xù)補(bǔ)一張自己的
從以上的架構(gòu)圖中，我們可以很清晰的梳理出各自的分工。
- View層：視圖展示。包含UIView以及UIViewController，View層是可以持有ViewModel的。
- ViewModel層：視圖適配器。暴露屬性與View元素顯示內(nèi)容或者元素狀態(tài)一一對(duì)應(yīng)。一般情況下ViewModel暴露的屬性建議是readOnly的，至于為什么，我們?cè)趯?shí)戰(zhàn)中會(huì)去解釋。還有一點(diǎn)，ViewModel層是可以持有Model的。
- Model層：數(shù)據(jù)模型與持久化抽象模型。數(shù)據(jù)模型很好理解，就是從服務(wù)器拉回來的JSON數(shù)據(jù)。而持久化抽象模型暫時(shí)放在Model層，是因?yàn)镸VVM誕生之初就沒有對(duì)這塊進(jìn)行很細(xì)致的描述。按照經(jīng)驗(yàn)，我們通常把數(shù)據(jù)庫、文件操作封裝成Model，并對(duì)外提供操作接口。(有些公司把數(shù)據(jù)存取操作單拎出來一層，稱之為DataAdapter層，所以在業(yè)內(nèi)會(huì)有很多MVVM的變種，但其本質(zhì)上都是MVVM)。
- Binder：MVVM的靈魂?？上г贛VVM這幾個(gè)英文單詞中并沒有它的一席之地，它的最主要作用是在View和ViewModel之間做了雙向數(shù)據(jù)綁定。如果MVVM沒有Binder，那么它與MVC的差異不是很大。
總結(jié)來說，MVC模式本來是完美的，但是隨著移動(dòng)時(shí)代的到來，前端數(shù)據(jù)展示、交互、跳轉(zhuǎn)變得復(fù)雜了，Controller的只能真的不適合在放到后端了，所以MVVM就出現(xiàn)了。
當(dāng)前題目：技術(shù)趨勢(shì)：是什么讓MVC悄然消失的？
網(wǎng)頁路徑：http://www.5511xx.com/article/dhsiiii.html
