個人總結：MVC和MVP的區別

摘要： 前言 各位老鐵，歷時20天我又回來了。時間嗖嗖就到年底了，才發現自己年初的計劃還沒開始，所以這一段時間都在專心研究後端的技術。剛開始接觸MVC和MVP的時候，一直都有一個疑問，他倆到底有什麼區別呢，面試的時候也經常被問到這個問題。我們都知道後端主要使用MVC，因為平臺的特殊性，Androi...

前言

各位老鐵，歷時20天我又回來了。時間嗖嗖就到年底了，才發現自己年初的計劃還沒開始，所以這一段時間都在專心研究後端的技術。剛開始接觸MVC和MVP的時候，一直都有一個疑問，他倆到底有什麼區別呢，面試的時候也經常被問到這個問題。我們都知道後端主要使用MVC，因為平臺的特殊性，Android根據MVC模式演變出MVP模式，廣泛的使用在開發中。

現在讓我們怎麼思考一下，為什麼在Android平臺演變出MVP模式？

本文參考了以下兩篇部落格，大家可以去閱讀原文：

ofollow,noindex">兩張圖看懂Android開發中MVC與MVP的區別

MVP與MVC的異同

正文

首先看一下MVC和MVP的對比圖（我直接偷來的）：

通過對比圖我們分析一下兩種模式的特點：

MVC
View：佈局的xml檔案，或者純Java寫的佈局，可以把頁面顯示的邏輯直接放在View中。
Model：資料處理層，可以直接和View進行互動。
Controller：把特定的功能邏輯抽離出來，作為控制層，保證View層和Model層的功能單一性，便於維護。

MVC模式相對比較簡單，尤其是View層，我們可以通過jsp等技術直接操作頁面，完成和Controlller層和Model層的互動，所以MVC的核心是在View層。

接下來我們再看看MVP模式：

MVP
View：Activity作為顯示層。
Presenter：邏輯層，從Activity中抽離出功能邏輯，簡化Activity的程式碼。
Model：資料處理層，主要負責網路請求，本地資料載入等操作，進一步簡化Activity的程式碼。

從MVP的構成來看，Presenter和Model都是為了View層存在的，所以MVP的核心仍然是View層。

MVP的演變

剛才我們分析了MVC和MVP的構成，我們發現MVP模式相比MVC模式要複雜：

MVC的View層和Model層本身就是分離的，Controller層主要是簡化View層的邏輯程式碼。
MVP的Presenter層和Model層都是為了拆分View層而存在的。

Activity在Android開發中扮演者重要的角色，頁面顯示，資料載入，各種事件，他一個人可以承擔所有相關的功能。雖然通過xml方便了佈局的開發，但是在與後端開發中的xml相比，他並沒有承擔起顯示UI的責任，所以Activity變得越來越龐大，輕輕鬆鬆就可以幾千行程式碼，非常不利於維護，為了讓View層單純的負責UI的顯示，把Activity中的功能邏輯抽離出來，命名為Presenter層，把資料相關的操作（介面，本地資料庫等）提取成Model層，並且直接把View層和Model層通過Presenter層解耦，進一步簡化Activity的程式碼，防止Activity體積過大。

MVC和MVP的區別

這裡主要說他們的不同點：

1、Presenter與Controller都扮演了邏輯層的角色，但是Presenter層的功能相對更復雜，因為他負責和View的雙向互動，Controller只是單向的中介。因為Presenter是從View層抽離出來的，通常和View是一對一的關係，而Controller是面向業務的，往往是單例模式或者提供靜態方法。
2、MVP中View和Model是不能進行通訊的，雖然加重了P層的負擔，但是有利於維護View層和Model層，如果條件允許，我們還可以對Presenter進一步拆分，來彌補Presenter負擔過重的問題。
3、MVC中View和Model層可以直接互動，雖然方便了兩者之間的互動，但是耦合性相對較高。

其他的不同點就不說了，本來兩種模式的出發點就不同，不同點那肯定匯出都是，細說這些其實沒有什麼太大意義。

總結

“Android為什麼沒有使用MVC，而是使用MVP?"

如果還有人再問我這樣的問題，我就可以輕鬆的說出我自己的見解，而不是毫無底氣的猜測。

沒有最好的架構模式。隨著業務的不斷增長，為了讓我們的程式碼變得更美觀，我們可能會多種模式混合使用，再或者在原本的模式上衍生出新的模式，這就是架構的魅力。看來我這20幾天還是沒白學的。

馬上要十一了，最後祝大家國慶愉快~