MVVM 開發的幾種模式討論(WPF)

2021-09-22 08:57:43 字數 2711 閱讀 2710

在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的場合

組裝車間

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

可動態替換所有view

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

大型系統的嚴格設計

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

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

出處:

標籤:

.net

wp8使用mvvm模式簡單例子

mvvm是silverlight wpf下的mvc昇華 通過乙個簡單的加法計算器例子來說明mvvm是什麼 在設計介面完成設計之後,顯示簡單的布局,如下圖 然後來比較,傳統的直接方式,mvc和mvvm三種的區別 1.最直接的方式無非就是雙擊button按鈕,在onclick事件中獲得兩個textbox...

wp8使用mvvm模式簡單例子

mvvm是silverlight wpf下的mvc昇華 通過乙個簡單的加法計算器例子來說明mvvm是什麼 在設計介面完成設計之後,顯示簡單的布局,如下圖 然後來比較,傳統的直接方式,mvc和mvvm三種的區別 1.最直接的方式無非就是雙擊button按鈕,在onclick事件中獲得兩個textbox...

C WPF開發之MVVM模式開發

mvvm模式由model,view,viewmodel三部分組成。model需繼承inotifypropertychange 屬性修改通知 viewmodel負責業務邏輯,連線view和model view上面的控制項繫結model和命令 command 注 資料繫結binding實現了inotif...