我是WPF菜鳥之(2) --- 適用於WPF的設計模式

導言:

經過前面的文章知道了WPF是幹什麼的，那在學習具體實現過程以前，咱們先了解一下 WPF的設計模式。

學習運用新技術當然是好，可是設計框架對於項目的開發及運維很重要。

 

正文：

有朝一日能把 軟件的UI設計和邏輯設計分開，這是多年來程序開發人員的夢想。現在，這個夢想被XAML+C#實現了，你們都很開心。開心事後，問題來了——Binding與依賴屬性再好使、路由事件和命令再靈活，若是不加約束地亂用和過分使用，同樣會致使軟件架構的不穩固以及招致維護、測試和調試方面的麻煩。

 

那麼，怎樣才能用好WPF帶來的結構上的新特性呢？咱們須要作的，不是從頭開始創造一個新模式，而是須要把WPF的新特性揉合進現有的、成熟的開發框架中去。下面，讓咱們開始WPF開發框架的演進之旅！

 

MVC時代

現有的開發框架林林總總，但萬變不離其宗，這個「宗」指的就是最爲經典的MVC模式。插一句，有一次面試一位候選人，當我問及這個模式的時候，這位兄臺乾脆地回答到：「MCV！」，因而我就讓他「展開」講講了:p

 

MVC框架出現的年代比較早，生成軟件UI和邏輯用的是同一種語言（好比C++/Java/Delphi），靈活性基本上是侷限在對於同一塊數據（由Model暴露出來）使用不一樣的視圖（View，也就是UI）展示給用戶。

 

MVP時代

隨着互聯網的發展，程序再也不是一個個只能跑在特定操做系統上的代碼塊，成千上萬的用戶但願使用相同的程序共享相同的數據。操做系統平臺一時半會是統一不起來了，A廠商程序跨到B廠商平臺上的那隻腳也每每被B廠商穿上一隻小鞋。萬般無奈下，開發人員只好訴諸於全部操做系統平臺的交集——瀏覽器——趕鴨子上駕般地作起了程序的宿主；HTML也沒被放過，原本用於簡單呈現頁面的標籤語言卻被CSS、JavaScript、XML等等武裝到了牙齒。

 

Anyway，程序能夠跑在瀏覽器裏了，須要開發人員從新把程序開發一遍嗎？人們發現，不管程序的前端（UI部分）跑在哪裏，它的後臺邏輯是不會改變的。因而人們開始想：我怎樣才能把UI和邏輯解耦並對邏輯層加以複用呢？必須要在設計或者重構的時候考慮上這一點才能夠。

 

因而，在MVC的基礎上，人們向前推動了一步——MVP模式誕生了（有玩兒文字遊戲的嫌疑哦！）。Interface這個詞被譯成「接口」以後就丟了些本來的意思。若是還把當譯成「界面」，那麼這個意思就能找回來了——現實世界也是這樣，當物體受到接力的時候，凡有界面的地方就是最容易被撕下來的地方。所以，interface這個詞在譯成中文時，「接口」傳達的是其能夠做爲公共約束（契約）的一層意思；「界面」則能傳達解耦的一層意思。

 

在MVP模式中，爲了讓UI層可以從邏輯層上「撕」下來，設計師們在UI層與邏輯層之間加了一層interface。不管是UI開發人員仍是數據開發人員，都要尊重這個契約、按照它進行設計和開發。這樣，理想狀態下不管是Web UI仍是Window UI就均可以使用同一套數據邏輯了。

 

MVVM時代

如今，WPF來了，它帶來了3D、動畫、音頻視頻……這致使了UI的變化將更加細節化、可定製化。同時，在技術層面，WPF也帶來了諸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。咱們怎樣才能立足於原有MVP框架、把WPF的新特性揉合進去，以應對客戶複雜的需求呢？

 

圖說MVP與MVVM

 

MVC模式大都已經很是熟悉了，咱就不說了。讓咱們看看它的升級版——MVP

 

 

 

從這張圖上咱們能夠看出以下幾點：

1. IView這個interface層幫助咱們把各種UI與邏輯層解耦

2. IView這層同時也爲自動化測試提供了入口（從UI層進入自動化測試，太麻煩了）

3. 傳統的、由WinForm/Web Form/MFC等編寫的UI是經過事件（本質是Windows 消息）與IView層溝通的。

4. WPF與IView層的溝通，最佳的手段是使用Binding，固然，也可使用事件

5. Presenter層要實現IView，多態機制能夠保證運行時UI層顯示恰當的數據。好比Binding，在程序中，你可能看到Binding的Source是某個interface類型的變量——實際上，這個interface變量引用着的對象纔是真正的數據源

6. 無關緊要的Control……有的話，就當是留個記念吧，原版的MVP圖裏是沒有Control的，Control被Presenter取代

7. 這裏的Presenter有點歧義之虞，就我我的而言，感受Presenter是UI裏的東西。

 

咱們再來看MVVM

 

一樣有幾點注意：

1. 當咱們只關注MVP模式與WPF結合的應用方式時，MVP就變成了MVVM。

2. 借鑑MVP的IView層，養成習慣。原版MVVM圖裏是沒有這層的，但我會在程序里加上這層。

3. View Model聽起來比Presenter要貼切得多

4. 我會把一些跟事件、命令相關的東西放在Controler裏