Android APP架構設計——MVC、MVP和MVVM介紹

0. 前言

爲了更好地進行移動端架構設計，咱們最經常使用的就是MVC、MVP和MVVM，做爲三個最耳熟能詳的三大架構，應用可謂很是普遍。本文原創，轉載請註明出處爲SEU_Calvin的博客。本篇博客將介紹這三種架構設計的工做原理以及優缺點，以及它們在Android中的表現。

 

1.   MVC

1.1    MVC工做原理

MVC是軟件架構中最多見的一種框架，三個字母分別表明三個模塊：Model、View和Controller。

MVC的工做原理：當用戶觸發事件後，View層會發送指令到Controller層，接着後者會去通知Model層更新數據，更新完數據後Model會通知View層數據的變化，並將新數據顯示在View上，具體見下圖，可見MVC把應用程序的邏輯層與界面層徹底解耦。

View和Controller使用策略模式實現，View使用組合模式實現，View和Model經過觀察者模式同步信息。

1.2    Android中的MVC

能夠說Android App本來就是MVC的，View對應佈局文件Xml，Controller對應Activity，Model對應數據庫、網絡請求、業務計算等操做。 舉個簡單的例子，按下界面上的一個Button去網絡上下載一個文件，這個按鈕是View層的，咱們是經過Xml來定義的，而網絡請求等複用性很高的相關代碼寫在一個專門的DownloadHelper類中，其實這就是咱們所說的Model層，最後經過button.setOnClickListener()函數將View層和Model層聯繫起來，這個函數就寫在了Activity中，即Controller層的實現。

1.3    MVC的缺點

MVC架構在Android中是存在很明顯的缺點的，問題就在於View層的XML控制力實在是太弱了，衆多View層的處理（好比在恰當的時刻控制某個控件的Visibility屬性）最終都放在了Activity中去作，這樣Activity有時候過於臃腫了，從而致使Activity既包含了View又包含了Controller，兩層之間耦合高，不利於維護拓展，可讀性也變差。同時從上圖MVC的工做原理中也發現View層和Model層之間也存在耦合。

正由於MVC存在的上述問題，因此才演化出了MVP和MVVM這兩種架構。

2.  MVP

2.1    MVP工做原理

MVP是軟件架構中最多見的一種框架，三個字母分別表明三個模塊：Model、View和Presenter。

Model：該角色主要是提供數據的存取功能。Presenter經過它來存儲、獲取數據。對應於項目中封裝了數據庫DAO或者網絡獲取數據的角色。

View：一般指Activity、Fragment或者某個View控件。它含有一個Presenter成員變量，一般View須要實現一個接口，View操做都交給Presenter去實現。

Presenter：View和Model的橋樑。它從Model層檢索數據後返回給View層，使得View和Model沒有耦合，同時也將業務邏輯從View層中抽離出來。

MVP的工做原理：當View接受用戶的交互請求後，將請求轉交給Presenter ，Presenter操做Model進行數據更新 ，更新以後Model通知Presenter數據發生變化 ，最後Presenter通知View顯示新數據 。具體見下圖。

2.2    MVP和MVC的區別

很明顯地相對於MVC來講View 與 Model 再也不發生聯繫，都經過Presenter 傳遞。

那麼爲了防止View層和Presenter層出現耦合，對於View層和Presenter層的通訊，咱們是能夠經過接口實現的，具體的意思就是說咱們的Activity（View層）能夠去實現定義好的接口，而在對應的Presenter中經過接口調用方法從而操做View。具體能夠從2.3中給出的例子中感覺到。爲了確保文章的實時更新，實時修改可能出錯的地方，請確保這篇是原文，而不是無腦轉載來的「原創文」，原文連接爲：http://blog.csdn.net/seu_calvin/article/details/52909755。

2.3    MVP在Android中的使用示例

爲了控制本篇的篇幅，實例介紹在Android APP架構設計——MVP的使用示例中給出，請查看。

2.4    MVP的優勢

從2.3中的例子咱們能夠感覺到，MVP極大簡化了Activity中的代碼，將複雜的邏輯代碼提取到了Presenter中進行處理。與之對應的好處就是，各層之間的耦合度更低，更方便的進行測試，解決了MVC中維護難的問題。

 

2.5    MVP存在的問題

（1）MVP的問題之一在於，因爲咱們使用了接口的方式去鏈接View層和Presenter層，若是有一個邏輯很複雜的頁面，接口會有不少，維護接口的成本會很大。這個問題經過如下方案緩解：定義一些基類接口，把一些公共的邏輯，好比網絡請求成功失敗，toast等放在裏面，以後你再定義新的接口時能夠繼承自這些基類。

（2）因爲Presenter 常常性的持有Activity 的強引用，若是在一些請求結束以前Activity 被銷燬了，Activity對象將沒法被回收，此時就會發生內存泄露。解決方案已經在2.3中的連接文中給出了。

3.  MVVM

3.1  MVVM工做原理

MVVM(Model-View-ViewModel)：MVVM和MVP的區別其實不大，只不過是把Presenter層換成了ViewModel層，再有就是View層和ViewModel層是雙向綁定的關係，當咱們更新ViewModel層的數據的時候，View層會相應的更新UI。MVVM在Android中的實現方式是經過data-binding框架來作的，若是具體不瞭解該如何使用，能夠參考這篇文章，這裏就不作贅述了。爲了確保文章的實時更新，實時修改可能出錯的地方，請確保這篇是原文，而不是無腦轉載來的「原創文」，原文連接爲：http://blog.csdn.net/seu_calvin/article/details/52909755。

3.2  MVVM存在的問題

（1）數據綁定使得 Bug 很難被調試。你看到界面異常了，有多是你 View 的代碼有 Bug，也多是 Model 的代碼有問題。數據綁定使得一個位置的 Bug 被快速傳遞到別的位置，定位問題變得更麻煩。 
（2）對於過大的項目，數據綁定須要花費更多的內存。

關於APP的架構設計就介紹到這吧，轉載請註明出處：http://blog.csdn.net/seu_calvin/article/details/52909755

最後天冷了你們多加衣服~ 也請你們多點下面的「頂」支持~