MVC和MVP的一些思考

碧落

前言

這篇文章是我近期對MVC和MVP的一些思考，在使用MVC/MVP模式的過程中曾經走過一些彎路。呵呵，現在雖然改正了某些彎路，但不保證改正了所有的彎路（例如對渲染的理解），所以請閱讀這篇文章的朋友不吝發揮你們的質疑。

寫這篇文章也是想知道自己還有什么地方是錯的，我的最終方案是否可行？

有交流才會有進步。你有一個蘋果，我有一個蘋果，我們交換后仍各有一個蘋果，你有一個思想，我有一個思想，我們交換后......會有N個思想 :p

1. MVC的理解誤區

以下是我以前對MVC模式的理解誤區：

1. 認為Model是指失血模型的實體類（Entity），是作為View和Controller之間的傳輸數據。

2. 把業務邏輯全部放在Controller端，認為Controller是用來寫UI的業務邏輯的。

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

Model在MVC架構中起的作用非常重要，它才是UI業務邏輯真正的實現層。所以Model的實際上是Business Model（業務模型）。

而Controller僅僅起一個“橋梁”作用，它負責把View的請求轉發給Model，再負責把Model處理結束的消息通知View。Controller就是一個消息分發器。Controller是用來解耦View和Model的，具體一點說，就是為了讓UI與邏輯分離（界面與代碼分離）。

2. MVC與VCP的區別

MVC的View直接與Model打交道，Controller只轉發請求（View的請求）和通知（Model處理完之后的通知），不傳遞數據（業務結果），而是由View直接向Model拿數據。

MVP的View不與Model直接聯系，所有的請求、結果通知、數據傳遞都是通過Controller轉發，View和Model彼此不知道對方的存在。

3. MVC與MVP的相同點

無論是MVC還是MVP，View和Controller都是緊密聯系的，在WinForm模式下更顯得突出，View和Controller直接綁定在一起了（在一個類里面）。

MVC/MVP都是通過“通知”機制（觀察者模式，在C#中使用事件）來解決View和Controller的交互。

4. MVP框架的設計

在MVP框架里，用Presenter代替MVC的Controller，而且View不再與Model交互。

4.1. Presenter

Presenter的作用比Controller大得多，Controller只是一個純粹的消息分發器，而Presenter還負責傳遞Model的處理結果給View，并指導View的渲染。

注意，渲染我理解為UI的展現方式。

4.2. Presenter與Model

Presenter與Model使用接口隔離，Presenter直接調用Model的接口方法（比如IUserModel的FetchUserList()、SaveUser()等）。

4.3. Presenter與View

View與Presenter的交互使用觀察者模式，有兩種方式實現：

1. View主動使用Presenter。

View主動構造Presenter，并在內部調用Presenter的方法。即先有View再有Presenter。這種情況下，View明確知道自己要使用哪些Presenter。

2. Presenter主動使用View。

Presneter主動創建View，View里面定義有一堆的事件，Presenter注冊這些事件。這種情況下，View不知道自己會被哪些Presenter使用。

第二種方式比第一種方式耦合性低，但View里要寫一堆的事件，Presenter類里要捕獲一堆的事件，感覺寫起來很煩瑣，代碼不雅觀。

5. Controller/Presenter的意義

以下Controller/Presenter簡稱為C/P。

C/P存在的意義是為了解耦View和Model。如果C/P不存在的話，View就直接訪問Model，而View的變化是頻繁的，不同的系統，View的展現方式不一樣，讓Model去控制View的渲染，會降低Model的重用性。如果Model不管View的渲染，由View自己渲染，那么就是WinForm的解決方式，即View和C/P經綁定（合并為一個類）。

6. 為什么要用MVC/MVP模式？

老實說，到目前為止，我依然看不出WinForm把Model分離之后，與標準的MVC/MVP有什麼差距。在WinForm分離Model之后，兩者的交互可以用接口隔離，也可以用觀察者模式讓Form與Model一對多。再用IoC替代View直接構造Model的實例，那么WinForm代表的View+C/P（Form）已經與Model完全解耦了，View+C/P層連Model層都不需要引用（但要引用IModel層）。

這里關鍵是使用IoC技術，否則WinForm確實會導致View與Model直接耦合，更換Model，或者改變Model的接口會導致View要修改。注意，我們分離出來的Model，并不完全是為了使UI與代碼分離，我們更注重Model的重用性，力求一個Model被多個View享用，甚至是不同系統的View享用。這就要求我們改動View的渲染時不用改動Model，同樣地，我們改動Model的內部邏輯時，也不影響View的渲染。

嗯，或許還有一點：View通過Controller/ Presenter交互，使得系以統可以有一個共同的“入口”，系統可以在入口處做攔截，利于日志和權限的處理。但我們可以用AOP技術替代C/P的入口。

7. 新方案

由此看來，IoC+AOP可以完全替代C/P，而且框架上更“干凈”，開發人員寫起來更自由。

一些零碎的想法，有什么錯誤的地方請大家多多指教，謝謝。

碧落 于2009年3月6日凌晨