淺談Android中MVP模式與MVC模式的區別
一、概述
對於MVP(Model View Presenter),大多數人都能說出一二:“MVC的演化版本”,“讓Model和View完全解耦”等等。本篇博文僅是為了做下記錄,提出一些自己的看法,和幫助大家如何針對一個Activity頁面去編寫針對MVP風格的程式碼。
對於MVP,我的內心有一個問題:
為何這個模式出來後,就能被廣大的Android的程式設計師接受呢?
問了些程式設計師,他們對於MVP的普遍的認識是:“程式碼很清晰,不過增加了很多類”。我在第一次看到MVP的時候,看了一個demo,看完以後覺得非常nice(但是回過頭來,自己想個例子寫,就頭疼寫不出來,當然這在後文會說)。nice的原因還是因為,這個模式的確讓程式碼的清晰度有了很大的提升。
那麼,提升一般都是對比出來的,回顧下,沒有應用MVP的程式碼結構。很多人說明顯是MVC麼:
View:對應於佈局檔案
Model:業務邏輯和實體模型
Controllor:對應於Activity
看起來的確像那麼回事,但是細細的想想這個View對應於佈局檔案,其實能做的事情特別少,實際上關於該佈局檔案中的資料繫結的操作,事件處理的程式碼都在Activity中,造成了Activity既像View又像Controller(當然了Data-Binder的出現,可能會讓View更像View吧)。這可能也就是為何,在該文中有一句這樣的話:
Most of the modern Android applications just use View-Model architecture,everything is connected with Activity.
而當將架構改為MVP以後,Presenter的出現,將Actvity視為View層,Presenter負責完成View層與Model層的互動。現在是這樣的:
View 對應於Activity,負責View的繪製以及與使用者互動
Model 依然是業務邏輯和實體模型
Presenter 負責完成View於Model間的互動
ok,先簡單瞭解下,文中會有例子到時候可以直觀的感受下。
小總結下,也就是說,之所以讓人覺得耳目一新,是因為這次的跳躍是從並不標準的MVC到MVP的一個轉變,減少了Activity的職責,簡化了Activity中的程式碼,將複雜的邏輯程式碼提取到了Presenter中進行處理。與之對應的好處就是,耦合度更低,更方便的進行測試。借用兩張圖(出自:該文),代表上述的轉變:
轉換為:
二、MVP 與 MVC 區別
ok,上面說了一堆理論,下面我們還是需要看一看MVC與MVP的一個區別,請看下圖(來自:本文):
其實最明顯的區別就是,MVC中是允許Model和View進行互動的,而MVP中很明顯,Model與View之間的互動由Presenter完成。還有一點就是Presenter與View之間的互動是通過介面的(程式碼中會體現)。
還有一堆概念性的東西,以及優點就略了,有興趣自行百度。下面還是通過一些簡單的需求來展示如何編寫MVP的demo。
三、MyMvp demo
效果圖:
我們來看一下專案的結構:
我自己還沒看透,以下我就不細說了,感興趣的話大家可以自己研究研究。