MVC, MVP和MVVM都是用來解決介面呈現和邏輯程式碼分離而出現的模式。以前只是對它們有部分的瞭解，沒有深入的研究過，對於一些裡面的概念和區別也是一知半解。現在一邊查資料，並結合自己的理解，來談一下對於這三種模式思想的理解，以及它們的區別。歡迎各位高手拍磚。

閱讀目錄:

一. MVC, MVP, MVVM誕生的需求?

二. 一段典型的耦合程式碼

三. MVC模式

     3.1 主動MVC

     3.2 被動MVC

     3.3 Web應用中的MVC框架

     3.4 MVC總結

一，MVC, MVP, MVVM誕生的需求?

軟體中最核心的，最基本的東西是什麼? 是的，是資料。我們寫的所有程式碼，都是圍繞資料的。
圍繞著資料的產生、修改等變化，出現了業務邏輯。
圍繞著資料的顯示，出現了不同的介面技術。 

沒有很好設計的程式碼，常常就會出現資料層(持久層)和業務邏輯層還有介面程式碼耦合的情況。

ORM等框架，解耦合了業務邏輯和資料之間的耦合，業務邏輯不再關心底層資料如何儲存和讀取。所有資料呈現給業務邏輯層的就是一個個的物件。
而MVC, MVP, MMVM用來解決業務邏輯和檢視之間的耦合。

二，一段典型的耦合程式碼

{

SqlDataAdapter adapter = new SqlDataAdapter("select * from Table1","server=.;database=db;uid=sa;pwd=password");

DataSet ds = new
 
 DataSet("ds1");

adapter.Fill(ds);

this.GridView1.DataSource = ds;

this.GridView1.DataBind();

}

上面的這段程式碼中，既包含了資料訪問，還包含的頁面展示。當專案複雜程度更高，這種程式碼就會變得非常難以維護，層次也不清晰。

三，MVC模式

MVC全名是Model View Controller，是模型(model)－檢視(view)－控制器(controller)的縮寫。MVC開始是存在於桌面程式中的，M是指業務模型，V是指使用者介面，C則是控制器，使用MVC的目的是將M和V的實現程式碼分離，從而使同一個程式可以使用不同的表現形式

3.1 主動MVC

MVC的理論思想對應的是主動MVC, 這裡的主動的意思是, Model會主動通知View更新。而我們使用MVC框架, Struts, asp.net mvc等都不是主動MVC(檢視的更新都是通過Controller完成的)

Model

用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。
模型中資料的變化一般會通過一種重新整理機制被公佈。為了實現這種機制，那些用於監視此模型的檢視必須事先在此模型上註冊，從而，檢視可以瞭解在資料模型上發生的改變。

View

檢視層負責資料的展示。
在檢視中一般沒有程式上的邏輯。為了實現檢視上的重新整理功能，檢視需要訪問它監視的資料模型（Model），因此應該事先在被它監視的資料那裡訂閱Model的事件。

Controller

控制器是M和V之間的聯結器，用於控制應用程式的流程。它處理事件並作出響應。“事件”包括使用者的行為和資料模型上的改變。

3.2 被動MVC

下圖是被動MVC中的流程，和主動MVC不同之處是, View沒有訂閱Model資料變化的事件，等待Model來通知需要根據新的資料來更新View. 在被動MVC中，Controller負責通知View, 有資料變化，需要更新檢視。

被動MVC 中，與主動MVC的區別在於：
1、模型對檢視和控制器一無所知，它僅僅是被它們使用
2、控制器使用檢視，並通知它更新資料顯示
3、檢視僅僅是在控制器通知它去模型取資料的時候它才這麼做(檢視並不會訂閱或監視模型的更新) 

3.3. Web應用中的MVC框架

Web中的MVC框架都是被動MVC模式，因為web應用中, 由於http是基於請求和響應方式協同工作的,因此當伺服器端的model(資料)發生變化時,它不會立即更新客戶端的view,只有客戶端重新請求或重新整理頁面時才更新.

下圖是典型的MVC框架中的MVC一個請求流程。

3.4 MVC總結

MVC優點

• 由於MVC很好的分離了檢視層和業務層，所以它具有以下優點
• 耦合性低
• 開發速度快
• 可維護性高
• 沒有控制元件的概念，對html沒有封裝，易於理解
• 和其它平臺(java, php)等更加相似。便於人才獲取

MVC使用的誤區

1.把Model理解成實體類（Entity），在MVC中Model應該包含2部分功能，一部分是處理業務邏輯，一部分是提供View顯示的資料
2.把業務邏輯全部放在Controller端

這兩個誤區本質上都是對Model的作用不明導致的。

Model在MVC架構中起的作用非常重要，它應該是業務邏輯真正的實現層。所以Model的實際上是Business Model（業務模型）。而Controller僅僅起一個“橋樑”作用，它負責把View的請求轉發給Model，再負責把Model處理結束的訊息通知View。Controller是用來解耦View和Model的，具體一點說，就是為了讓UI與邏輯分離（介面與程式碼分離）。

Techopedia explains Model (MVC)

The Model is the part of MVC which implements the domain logic. In simple terms, this logic is used to handle the data passed between the database and the user interface (UI).

The Model is known as domain object or domain entity.
The domain objects are stored under the Models folder in ASP.NET. The domain model represents the application perspective for the data to be handled whereas a view model is required to produce the engine that generates the View.

This definition was written in the context of ASP.NET.

MVC的缺點

完美的MVC應用場景應該是這樣的:

有個Student Model, 關聯StudentListView,  StudentEditView.
對於StudentListView, Student Model提供Student的集合資料來顯示StudentListView
對於StudentEditView, Student Model提供單個Student資料來展示StudentEditView並且響應StudentEditView的儲存操作。

但是這只是完美的情況，實際應用中，在ListView上，不單單顯示Student的資訊，可能還需要這個Student的歷史成績，家庭情況,  老師資訊。而這些是Student Model不能提供的。
也許我們可以擴充套件Student Model, 將Student Model能夠提供的資訊擴充套件，包含成績資訊等，這本身也可以。但是，如果Student顯示的View，這個需要只是需要額外的成績資訊，另一個View只是需要額外的家庭資訊，Student Model是不是有些疲於奔命，你能知道還會有多少個差異化的View的需求? 而且讓邏輯端程式碼這樣不斷的修改來適應View端，好嗎?

由於MVC的設計思想是從Model出發，而沒有考慮到View端的複雜性，這樣導致的問題是Model難以符合複雜多變的View端變化。
相對這點，MVP和MVVM就要好得多。它們都獨立出了Presenter 和ViewModel來對應每個View。