淺談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
效果圖：
我們來看一下專案的結構：
我自己還沒看透，以下我就不細說了，感興趣的話大家可以自己研究研究。