MVVM 開發的幾種模式討論（WPF）

在wpf系(包括sl,wp或者win8)應用開發中，mvvm是個老生常談的問題。初學者可能不會有感覺，但當你寫乙個核心邏輯能在各種平台上無縫移植，而只需改改ui的時候，那種快感是無法用語言來形容的。

筆者當初接觸時，對mvvm並不以為然，編了很多**以後，反過來看mvvm for wpf的經典文章以後，才若有頓悟。標準的mvvm把程式分成了model, viewmodel和 view三個部分，但方法是死的，人是活的。我一般的做法是邏輯寫乙個，view寫乙個，沒有那麼嚴格。為了方便討論，我們把viewmodel和model合稱model, view還是view, 分別代表邏輯和介面。分離是肯定的，可是在程式中終究是要把view和model在某個地方結合起來。本文就討論下幾種結合的方式。

標準的mvvm，做法當然是先設計model, 然後再設計view, 在view的**裡有且僅有這麼幾句話：

public
partial
class pluginmangerui : usercontrol
}

基本的邏輯結構可以用下圖來表示。不同的庫是由自底向上的方式設計的。

這種由view呼叫model, 並具體由view負責model例項化的方式是最為普遍的，非常適合於需要跨平台的應用。當然，model並不知道view的存在，因此view要承擔所有的介面邏輯，好在wpf已經給出了足夠多的解決方案，觸發器，模板。基本絕大多數需求都能滿足。

這種做法，是筆者經常用的。在model裡，通過以下**來實現介面生成

internal
class viewexample : usercontrol 
public
class modelexample : iview
public
object usercontrol
}

肯定會有同學問道，怎麼會有這麼奇怪的寫法？這種做法的最常見場合應該是外掛程式系統。乙個個的model其實是乙個個的外掛程式，它們應該具備自治性。因此，應該由自身負責介面的產生。

它的好處是可以通過model更加精細的調節view的行為，你可以在任何時候獲得view內部listbox的selectindex, 而不用麻煩的用binding。打個比方說，遊戲開發中，你需要隨時控制物體的運動速度和方向，這樣model就必須控制view. 繫結很難解決這類問題。

我不知道有多少同學在wpf中使用外掛程式的設計思想。若按外掛程式的思路，庫應該按功能劃分。在這種設計思路下，不同的庫便不是自下而上的分層了，而是通過領域和功能分層，如下圖：

每乙個功能庫都有完整的自治性，當你將該功能庫拷貝到主框架之下時，它就會自動載入，由model負責view的生成。一切合情合理。

這種思路來自於工廠方法，類似於裝配車間，view和model都不負責互相的例項化。而有乙個「管理器」負責組裝它們。這樣的好處在於可配置。你可以通過配置檔案動態的改變view.

我記得一種比較著名的wpf嚮導（wizard）就是這樣的設計思路：

private
static list> createsteps(dataprocesstask o)
,new completestep,
new completestep,
new completestep,
new completestep};}

如上圖所示，dataprocesstask類是控制整個流程的核心，第一步先例項化所需的viewmodel, 第二部，通過構建乙個list列表，將view的type的方法傳到列表中。最終管理器通過反射來例項化view,並將datacontext繫結到對應的viewmodel完成整個組裝過程。

可以看出，這種做法徹底的隔絕了view和model, 同時通過配置選項，可以隨時修改view。可謂是一種不錯的設計。但是，必需看到，對於view來說,model沒有任何管理的許可權。下圖展示了它的基本邏輯：

如果最終你依舊需要兩邊互相控制，可以考慮採用dynamic關鍵字。

其實沒有哪種方式是最好的，完全是看你對整個系統的設計需求。但不論如何，介面和邏輯的分離，這是毋庸置疑的。下面的**總結了幾種做法的特點和適用場合：

名稱組裝邏輯

適用場合

缺點備註

標準mvvm

view例項化model

常用的跨平台場合

model無法控制任何view

適用於自底向上的分層設計

model例項化view

外掛程式結構或用於遊戲開發

存在一定的耦合

適用於按功能劃分的外掛程式型類庫設計，或要求model大量控制view的場合

組裝車間

第三方管理器例項化和組裝model和view

可動態替換所有view

兩者徹底隔絕，沒有控制靈活性

大型系統的嚴格設計

當然，如果用mvvmlight等第三方類庫的話，就應該按照它的方案去開發。但我們的原則是，解決問題，但不要引入更複雜的問題。為了解耦，搞了大量的複雜邏輯，反而捨本逐末。

有任何問題，歡迎隨時討論。

出處：

標籤:

.net

MVVM 開發的幾種模式討論（WPF）

wp8使用mvvm模式簡單例子

wp8使用mvvm模式簡單例子

C WPF開發之MVVM模式開發

MVVM 開發的幾種模式討論（WPF）

wp8使用mvvm模式簡單例子

wp8使用mvvm模式簡單例子

C WPF開發之MVVM模式開發

相關推薦