這篇文章是我近期對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，而且框架上更“干淨”，開發人員寫起來更自由。
