這篇文章是我近期對(duì)MVC和MVP的一些思考，在使用MVC/MVP模式的過程中曾經(jīng)走過一些彎路。呵呵，現(xiàn)在雖然改正了某些彎路，但不保證改正了所有的彎路（例如對(duì)渲染的理解），所以請(qǐng)閱讀這篇文章的朋友不吝發(fā)揮你們的質(zhì)疑。
　　寫這篇文章也是想知道自己還有什么地方是錯(cuò)的，我的最終方案是否可行？

　　有交流才會(huì)有進(jìn)步。你有一個(gè)蘋果，我有一個(gè)蘋果，我們交換后仍各有一個(gè)蘋果，你有一個(gè)思想，我有一個(gè)思想，我們交換后......會(huì)有N個(gè)思想 :p

　　1. MVC的理解誤區(qū)

　　以下是我以前對(duì)MVC模式的理解誤區(qū)：

　　1. 認(rèn)為Model是指失血模型的實(shí)體類（Entity），是作為View和Controller之間的傳輸數(shù)據(jù)。

　　2. 把業(yè)務(wù)邏輯全部放在Controller端，認(rèn)為Controller是用來寫UI的業(yè)務(wù)邏輯的。

　　這兩個(gè)誤區(qū)本質(zhì)上都是對(duì)Model的作用不明導(dǎo)致的。

　　Model在MVC架構(gòu)中起的作用非常重要，它才是UI業(yè)務(wù)邏輯真正的實(shí)現(xiàn)層。所以Model的實(shí)際上是Business Model（業(yè)務(wù)模型）。

　　而 Controller僅僅起一個(gè)“橋梁”作用，它負(fù)責(zé)把View的請(qǐng)求轉(zhuǎn)發(fā)給Model，再負(fù)責(zé)把Model處理結(jié)束的消息通知View。 Controller就是一個(gè)消息分發(fā)器。Controller是用來解耦View和Model的，具體一點(diǎn)說，就是為了讓UI與邏輯分離（界面與代碼分離）。

　　2. MVC與VCP的區(qū)別

　　MVC的View直接與Model打交道，Controller只轉(zhuǎn)發(fā)請(qǐng)求（View的請(qǐng)求）和通知（Model處理完之后的通知），不傳遞數(shù)據(jù)（業(yè)務(wù)結(jié)果），而是由View直接向Model拿數(shù)據(jù)。

　　MVP的View不與Model直接聯(lián)系，所有的請(qǐng)求、結(jié)果通知、數(shù)據(jù)傳遞都是通過Controller轉(zhuǎn)發(fā)，View和Model彼此不知道對(duì)方的存在。
　　
　　3. MVC與MVP的相同點(diǎn)

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

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

　　4. MVP框架的設(shè)計(jì)

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

　　4.1. Presenter

　　Presenter的作用比Controller大得多，Controller只是一個(gè)純粹的消息分發(fā)器，而Presenter還負(fù)責(zé)傳遞Model的處理結(jié)果給View，并指導(dǎo)View的渲染。

　　注意，渲染我理解為UI的展現(xiàn)方式。

　　4.2. Presenter與Model

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

　　4.3. Presenter與View

　　View與Presenter的交互使用觀察者模式，有兩種方式實(shí)現(xiàn)：

　　1. View主動(dòng)使用Presenter。

　　View主動(dòng)構(gòu)造Presenter，并在內(nèi)部調(diào)用Presenter的方法。即先有View再有Presenter。這種情況下，View明確知道自己要使用哪些Presenter。


　　2. Presenter主動(dòng)使用View。

　　PresNETer主動(dòng)創(chuàng)建View，View里面定義有一堆的事件，Presenter注冊(cè)這些事件。這種情況下，View不知道自己會(huì)被哪些Presenter使用。

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

　　5. Controller/Presenter的意義

　　以下Controller/Presenter簡(jiǎn)稱為C/P。

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

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

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

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

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

　　7. 新方案

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

　　一些零碎的想法，有什么錯(cuò)誤的地方請(qǐng)大家多多指教，謝謝。

NET技術(shù)：MVC和MVP的一些思考，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。