?

序： 讓我們首先通過現實的例子來看看 Model、View、Presenter 應該如何分工吧。View 就像是客服人員（或者留學中介里的顧問），Model 是那些具體的技術支持人員（或者文案，專門處理簽證申請材料），Presenter 是組長或部門經理。

View 不需要做太多的具體事情，他們最好相貌好點，聲音甜點，對用戶友好點，讓用戶心情舒暢就好，用戶的最終問題最終還是由具體的技術人員（技術支持，售后）處理。對于個體戶，小作坊，工作室來說，客服、技術可能一人包了，這樣效率最高，但后來你發現所有問題都你一個人處理，一個人不可能三頭六臂，事必躬親最終只能做作坊；這是單層結構。

所以你招聘了新的員工讓他們負責具體技術問題處理，你專心做客服，這樣你能承接的業務量大了，當然代價是工作效率低了成本高了，但這是做大必須要付出的代價；這是兩次結構。

后來你的公司規模越來越大，你就發現人員之間關系復雜，相互之間依賴嚴重，管理起來頭緒繁多；并且分工不明確，權責不分明，扯皮時有發生，很多問題接踵而來。現在你才發現，管理不正規化是很難做大做強的，因此，你進行了組織結構調整并建立起專業化的互補團隊，他們各司其職，你只要管理好你的經理層，整個企業就能做的很好。每個部門都有自己明確的職責，每個部門內部都有幾個相互合作的小組或團隊，部門經理的核心工作就是協調，讓合適的人（團隊）做合適的事情。同時不鼓勵培養全能型員工，因為不可能所有的員工都能全能，而依賴于少數全能員工無疑是有風險的，所以盡量分工細化，盡量使員工的工作簡單（這樣很容易找到合適的替換人員），盡量培養互補的專業化人才。

這樣整個公司就比較和諧，代價就是溝通成本更高了，公司僅僅因此付給管理層的薪水就很可觀，但沒辦法，要做世界 500 強，不舍得出血是不可能的。

當然，并不是付了這些成本就可以做世界 500 強，要想做好首先要規劃好，應該如何分工應該如何協作，其次要找好管理者協調好各部門各組織的工作，否則不但增加了成本反而會使整個系統更混亂。

同樣的道理，能不能做好一個系統與使不使用 MVP 或者 MVC 這些模式其實沒有必然的關系，并不會應為使用了 MVP 項目就會成功，同樣也不能將項目失敗的原因歸結到 MVP 或者 MVC 這些模式，而說它們不好。謀事在人，成事也在人。能否領會到 MVP 的優缺點，能否準確的判斷你的團隊能否駕馭 MVP 才是關鍵。

一、View 設計參考

View 和 Presenter 的設計應該以用例（Use Case）為基礎，以面向對象設計原則為準則。StopLight?和 BankBranchWorkbench 參考實現就是根據用例進行設計的。

根據面向對象的設計原則，對象的職責要明確單一（強內聚），對其他對象的細節了解的越少越好，盡量的只需要關心別人的接口，而不必關心別人的實現。StopLight 的設計可以給我一些啟示：

StopLight 的 View 有 StopLightView 是 IStopLightView 組成。

IStopLightView 接口定義了 View 在該用例中具有的能力，IStopLightView 的職責是告訴 Presenter 我能夠提供什么服務，你能夠從我這獲得什么信息：

????public?interface?IStopLightView?:?INotifyPropertyChanged
????{
????????Color?CurrentColor?{?get;?set;?}
????????string?GreenDuration?{?get;?set;?}
????????string?YellowDuration?{?get;?set;?}
????????string?RedDuration?{?get;?set;?}
????????event?EventHandler?UpdateClicked;
????????event?EventHandler?ForceChangeClicked;
????????void?SetError(string?propertyName,?string?errorMessage);
?????}?

?

也就是說 View 的實現應該允許我們設置并獲取當前顯示的顏色， 運行我們設置并獲取每種顏色的顯示時間間隔，運行我們告訴它有錯誤發生（具體它如何處理該錯誤信息我們不關心），同時在通供用戶接口并且在用戶操作后通知我們，具體我們要做什么，View 接口也不關心。

StopLightView 是 IStopLightView 接口的具體實現，它繼承自 UserControl ，因此是 WinForm 類型的界面。作為用戶控件對象，其核心職責是表現，給用戶提供友好的用戶接口，包括美觀的布局和方便的操作，而不用關心業務邏輯。

在實現 IStopLightView 接口方面，StopLightView 始終恪守本分，不做任何與自己無關的事情，只負責將自身包含的子控件屬性的讀寫（包括 ErrorProvider），提供事件注冊接口，并在屬性更改時發布通知（利用事件實現發布訂閱模式）。

通過閱讀 StopLightView 的代碼我們看到，雖然 StopLightView 強依賴于 StopLightViewPresenter ，但整個 StopLightView 只使用了 StopLightViewPresenter 的 View 屬性和 OnViewReady() 方法，而這兩個方法（屬性）都是抽象類 Presenter<TView> 已經定義的，也就是說即使我們沒有對 StopLightViewPresenter 做任何開發，StopLightView 也是可以編譯通過的。

因此 IStopLightView 接口只負責提供屬性，事件定義和操作接口，這些和界面相關，是用戶接口（UI）的職責范圍，但 IStopLightView 對具體的實現形式及頁面布局沒有任何要求，我們可以使用 Winform 實現，也可以使用 WPF、SilverLight，甚至我們可以使用 ASP.NET 或者 AJAX 來實現，實現者也不會有對界面布局方式，操作方式的約束，只要他們能夠實現 IStopLightView 接口就一切 OK 。

這就是職責單一！這就是松耦合！這給我們以后維護界面，更改界面帶來了極大的方便；同時，對于團隊開發，我們完全可以把 UI（UX） 設計與程序業務邏輯設計分開，也因此方便了我們對 UI 及業務邏輯的協作開發和分離測試。

二、Presenter 設計參考

在前一篇中，我們已經簡單的看了 Presenter 對 MVP 架構的支持，現在我們再仔細的看看 Presenter<TView> （public abstract class Presenter<TView> : IDisposable）。

所有具體的 SCSF Presenter 都應該繼承自抽象基類? Presenter<TView> 。該抽象基類提供了 MVP 模式的基本框架，是 MVP 模式的核心。

Presenter 的主要職責就是用于協調 View 和 Model，在 StopLight 項目中是通過依賴注入與 Model 建立了聯系，而在典型的 SCSF 中，Presenter 與 Model 的關系應該通過 WorkItem 建立 。

每個 Presenter 都有一個當前 WorkItem 實例：

????[ServiceDependency]
????public?WorkItem?WorkItem
????{
????????get?{?return?_workItem;?}
????????set?{?_workItem?=?value;?}
????}?

[ServiceDependency] Attribute 告訴?ObjectBuilder?把環境中的當前WorkItem 實例附給當前 Presenter 的 _workItem 字段。以后任何 Presenter 實例都可以通過當前的 WorkItem 獲取需要的資源，包括已注冊的 Services，SmartParts，Commands，State，UIExtentions 等。

Presenter<TView> 中還有三個虛方法，兩個 public 一個 protected 。

????????///?<summary>
????????///?在具體?View?的?OnLoad?方法中調用
????????///?</summary>
????????public?virtual?void?OnViewReady()?{?}
????????///?<summary>
????????///?在?TView?被設置時調用
????????///?</summary>
????????protected?virtual?void?OnViewSet()?{?}
????????///?<summary>
????????///?在?Dispose?中調用
????????///?</summary>
????????public?virtual?void?OnCloseView()?{?}

?

具體 Presenter 子類可以重寫上面三個方法來做必要的工作（這與 Form 編程中的 OnLoad等方法類似，很容易理解）。

在執行順序上， OnViewSet() 在 Presenter 類設置 View 屬性時最先被調用：

????????//?Presenter<TView>?類中的?View?屬性，set?時調用?OnViewSet()?方法
????????public?TView?View
????????{
????????????get?{?return?_view;?}
????????????set?{?_view?=?value;?OnViewSet();?}
????????}?

?

根據前面講的，View 被創建時會自動創建對應的 Presenter 并將 View 實例附給該 Presenter，因此 OnViewSet() 在 View 被創建后初始化時調用，這時 View 和 Presenter 都已經創建，可以做進一步初始化。StopLight 項目中的 StopLightViewPresenter 重寫了 OnViewSet() 方法，在里面調用了私有方法 wireEvents() ：

????????private?void?wireEvents()
????????{
????????????View.PropertyChanged?+=?OnViewPropertyChanged;
????????????View.UpdateClicked?+=?OnViewUpdateClicked;
????????????View.ForceChangeClicked?+=?OnViewForceChangeClicked;
????????????Schedule.ChangeLight?+=?delegate?{?Stoplight.Next();?};
????????????Stoplight.Changed?+=?OnStoplightChanged;?
????????}?

?

該方法將事件處理器和事件發布者進行了綁定，這是構建松散耦合應用的另一重要方式。

OnViewReady() 方法在具體 View 的 OnLoad 方法中調用：

????????///?<summary>
????????///?在?View?加載時允許?Presenter?注入適當的操作。開發者可以在?Presenter?中重寫?OnViewReady()?介入視圖加載過程。
????????///?</summary>
????????///?<param?name="e"></param>
????????protected?override?void?OnLoad(EventArgs?e)
????????{
????????????_presenter.OnViewReady();
????????????base.OnLoad(e);
????????}?

OnLoad 在第一次顯示窗體前調用，這時基本的初始化工作可以完成，子程序可以做進一步的初始化，如分配控件使用的資源。StopLightViewPresenter 重寫了 OnViewReady () 方法，在里面調用了私有方法 initViewAndStart()：

????????private?void?initViewAndStart()
????????{
????????????View.GreenDuration?=?"3000";
????????????View.YellowDuration?=?"500";
????????????View.RedDuration?=?"5000";
????????????View.CurrentColor?=?Color.Green;
????????????Schedule.Update(TimeSpan.FromMilliseconds(3000),
?????????????????????????TimeSpan.FromMilliseconds(500),
?????????????????????????TimeSpan.FromMilliseconds(5000));
????????????Schedule.Start();
????????}?

?

至此，定時器開始工作，業務流程正式啟動。

每個用例都對應一組 View 和 Presneter 。 Presenter 是整個用例的大管家，控制協調中心，自己基本上不做具體事情，核心工作都是組織和協調。作為控制器，Presenter了解與該用例相關的所有事情，因此能夠將合適的事情指派給合適的人去處理。

三、Model 設計參考

上一篇說過，Model 在程序中是另一個被濫用的名詞，很多東西都可以歸為 Model ，我們這里把 Model 認為是與實際業務模型對應的程序模型，這些模型是對現實世界業務的建模。在 SCSF 中，Model 通常可以用一系列的 Services 來表示。

模型中對現實世界的實體進行的建模一般是比較穩定的，因此這部分變化小；現實中業務規則還有人們對業務規則的理解往往是變動的，我們通過 Presenter 來應對這種變化，這樣 Model、 Prestener、View 都可以通過這種松散耦合來達到開閉原則，從而使我們的系統有步驟的強大。因為開閉原則意味著我們原先做的工作都是有意義的，不會因為局部的改變而是我們推到重來。

獲取這種松散耦合的優勢最主要得益于面向對象語言的多態特性和里氏代換原則，當然這種優勢背后的代價就是使我們多寫了不少代碼，使程序對于一般人來說似乎變得復雜。

Model、View 、Presenter 設計要以用例（Use Case）為基礎，以面向對象設計原則為準則。力求職責單一，有選擇的面向抽象，構建易測試、易理解的松散耦合系統。

仔細想想 MVP 模式（或者 MVC）的分工與現實世界的分工原來是如此的一致，如此的和諧。View 就像是前臺的客服人員，Model 是實際的技術支持人員，Presenter 是他們的主管，這樣勢必會增加溝通的成本，但對于大公司這種成本是必須的，否則永遠不可能最大做強。

轉載于:https://www.cnblogs.com/jcomet/archive/2013/05/29/3105858.html

總結

以上是生活随笔為你收集整理的SCSF 系列：Smart Client Software Factory 中 MVP 模式最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。