MVC與MVP的區別

@in桂林理工大學

引用自部落格園-冰冥寒流 侵刪。

MVP與MVC有著一個重大的區別：在MVP中View並不直接使用Model，它們之間的通訊是通過Presenter (MVC中的Controller)來進行的，所有的互動都發生在Presenter內部，而在MVC中View會直接從Model中讀取資料而不是通過 Controller。

而MVP則是對MVC的進一步改造，以Andorid為例，實際上在MVC中很難區分Activity到底應該處於V還是C的角色，因為activity即包含了介面也包含了一部分邏輯處理。

MVP的出現就是為進一步分離業務邏輯和介面處理。在MVP中，M與V完全切斷聯絡，由P進行總控。

當V接收到了操作，將相應的請求傳遞到P，由P進行業務處理以及與M進行互動，同時P又在恰當的時機對view進行更新（介面 / 回撥方法 / 事件）

這樣V只需要暴露出介面，V與P通過介面通訊，一方面能夠將業務邏輯轉移至P，一方面通過介面使得P可以適配多個V。


從這幅圖可以看到，我們可以看到在MVC裡，View是可以直接訪問Model的！從而，View裡會包含Model資訊，不可避免的還要包括一些業務邏輯。

在MVC模型裡，更關注的Model的不變，而同時有多個對Model的不同顯示，及View。

所以，在MVC模型裡，Model不依賴於View，但是View是依賴於Model的。不僅如此，因為有一些業務邏輯在View裡實現了，導致要更改View也是比較困難的，至少那些業務邏輯是無法重用的。

Visual Studio等快速開發工具，讓我們很難把View和Controller分開，我們總是直接在View的事件響應函式裡完成了Controller的程式碼。而在ASP.NET和XAML裡，使用了一種叫做Code-Behind的技術，可以把View和Controller進行分離。這樣，View就可以完全由UI設計工程師來完成，而Controller由程式設計師來完成，兩者可以直接合成不需要像現在一樣再由程式設計師做很多的工作。

MVP是如何解決MVC的問題的？

在MVP裡，Presenter完全把Model和View進行了分離，主要的程式邏輯在 Presenter裡實現。而且，Presenter與具體的View是沒有直接關聯的，而是通過定義好的介面進行互動，從而使得在變更View時候可以 保持Presenter的不變，即重用！

不僅如此，我們還可以編寫測試用的View，模擬使用者的各種操作，從而實現對Presenter的測試–而不需要使用自動化的測試工具。

我們甚至可以在Model和View都沒有完成時候，就可以通過編寫Mock Object（即實現了Model和View的介面，但沒有具體的內容的）來測試Presenter的邏輯。

在MVP裡，應用程式的邏輯主要在Presenter來實現，其中的View是很薄的一層。 因此就有人提出了Presenter First的設計模式，就是根據User Story來首先設計和開發Presenter。在這個過程中，View是很簡單的，能夠把資訊顯示清楚就可以了。在後面，根據需要再隨便更改View， 而對Presenter沒有任何的影響了。

如果要實現的UI比較複雜，而且相關的顯示邏輯還跟Model有關係，就可以在View和 Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View，避免兩者之間的關聯。而同時，因為Adapter實現了View的介面，從而可以保證與Presenter之 間介面的不變。這樣就可以保證View和Presenter之間介面的簡潔，又不失去UI的靈活性。

在MVP模式裡，View只應該有簡單的Set/Get的方法，使用者使用者輸入和設定介面顯示的內容，除此就不應該有更多的內容，絕不容許直接直接訪問Model–這就是與MVC很大的不同之處。