架構模式的文章很多，好理解的沒有幾個。大部分文章出現的主要問題有：

沒有設定好作用域：前端MVC是改造過的MVC，和后臺MVC有明顯的區別，不能一概而論

沒有實際的例子：實際的例子對應日常的工作，沒有就很難產生共鳴，從而造成看一次忘一次的困擾。

沒有明確的目的：理解架構模式的真正意義是什么？虛擬DOM和組件化在MV*中的位置？

題目開的太大，一定有很多疏忽錯誤的地方，也懇請大家指出。

1. MV*

1.1 后端MVC與前端MVC

從實現上來說，主要可以分為后端MVC和前端MVC兩種。這兩種MVC的不同點如下：

可以看到，前端的MVC其實是為了解決前端復雜JS模塊化的問題，從后端MVC的V分出來的MVC，與后端MVC并沒有直接的關系。前端的MVC中，M占的比例很低，只指代數據。而后端V的比例很低，只有模版的部分。

1.2 MVC/MVP/MVVM

可以清晰的看出，這三個架構的區別在“M與V聯系”的部分。下面我們針對這一部分做一個對比：

Controller: 負責監聽View的用戶事件，得到數據后Controller做一些處理，然后渲染View。

當然，在一些后端MVC架構里，Model也可以直接渲染View模版，但這只是不同變種的實現，這里不多做討論。

但是隨時邏輯的復雜，這樣的處理遇到了很難調試的問題。由于View一定要運行在UI環境下，而且Model或者Controller和View強耦合，沒有辦法單獨驗證應用邏輯的正確性。當出了問題之后，因為各個模塊是耦合在一起的，也不能快速判斷究竟是哪個模塊出現的問題。因此，MVP模式出現了。

Presenter: 比起Controller，Presenter會調用View層提供的接口去渲染Model。這樣做有幾點好處：

面向接口編程

更好的解耦

方便做單元測試

現在P和V解耦了，P可以自己做單元測試了。軟件結構劃分的更加清楚，邏輯清晰并方便調試。但是這一切都來自于一個前提：View層要提供接口。當一個UI復雜起來的時候，View層需要提供的接口是很多的，這本身也是一種開發調試的成本。所以，MVVM應運而生。

ViewModel: 比起MVP中View需要自己提供API，MVVM在VM中構建一組狀態數據(state data)，作為View狀態的抽象。然后通過雙向數據綁定(data binding)使VM中的狀態數據(state data)與View中的顯示狀態(screen state)保持一致。這樣，VM中的展示邏輯只需要修改對應的狀態數據，就可以控制View的狀態，從而避免在View上開發大量的接口。

VM有沒有什么缺點？有的，當UI比較簡單的時候，使用VM就會使業務邏輯變得復雜，有過分設計的嫌疑。所以VM只適合復雜UI交互的項目。

2. 舉個栗子

栗子🌰：現在用戶下拉刷新一個頁面，頁面上出現10條新的新聞，新聞總數從10條變成20條。那么MVC、MVP、MVVM的處理依次是：

1. View獲取下拉事件，通知Controller

2. Controller向后臺Model發起請求，請求內容為下拉刷新

3. Model獲得10條新聞數據，傳遞給Controller

4. Controller拿到10條新聞數據，可能做一些數據處理，然后拿處理好的數據渲染View

MVC: 拿到UI節點，渲染10條新聞

MVP: 通過View提供的接口渲染10條新聞

MVVM: 無需操作，只要VM的數據變化，通過數據雙向綁定，View直接變化

3. 了解架構的意義

最大的意義是站在創造者的角度上去思考問題，他們為什么要這么設計，這樣做又有什么樣的好處。當然，也有助于我們理解其他相關的知識。等到未來的某一天，當我們遇到更復雜的情況，用今天的MVVM也不能解決的時候，就可以順著這樣的思考脈絡，重新進行架構設計，散發出自己的光。

備注：虛擬DOM與組件化

不管是虛擬DOM也好，還是組件化也罷，都是一種開發策略，而不是架構模式上考慮的問題。換句話說，它們與MV*是兩個維度上的事情。所以把虛擬DOM和組件化扯入到MVC，MVP，MVVM的差異中并沒有意義。

參考文獻

總結

以上是生活随笔為你收集整理的java mvc mvp mvvm_一篇文章了解架构模式：MVC/MVP/MVVM的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。