摘要

　　WPF企業內訓全程實錄由於文章比較長，所以一共拆分成了三篇，上篇WPF企業內訓全程實錄（上）主要講了基礎，這篇作為該實錄的中篇，起著承上啟下的作用,主要講解開發模式、團隊協作及應用框架。其實如果大家仔細看目錄，可以發現我安排的順序是首先講解最基本的概念和基礎內容、然後過渡到開發模式及框架、最後結合其他技術和專案實際運用，這也是學習並應用一門技術最好的流程。上篇實際上主要有兩個側重點：一則就是理清脈絡——歷史淵源、概念引入及基本闡述；二則是講解WPFBasic——主要講解WPF的每個知識點，涵蓋了WPF的方方面面；如果大家感興趣，可以下載程式碼進行仔細研究，如果有不懂的地方也可以參考我寫的

章節綱要

· 1.摘要

· 2.本文提綱

· 3.簡要介紹

· 4.WPF介紹

· 5.WPF基礎

· 6.WPF工具

· 7.WPF開發模式

· 8.WPF團隊協作

· 9.瞭解並使用MVVM框架

· 10.自己開發MVVM框架

· 11.其他技術引入

· 12.WPF專案及效能優化

· 13.部署與更新

· 14.總結

· 15.詳細技術索引

七. WPF開發模式

提到WPF開發模式（這裡通常所說的是Presentation模式，其他層的模式不在此列），大家可能會立馬想到MVC/MVP/MVVM模式：

1，MVC：模型－檢視－控制器（Model View Controller)

2，MVP：模型－檢視－表現類（Model-View-Presenter）

3，MVVM：模型－檢視－檢視模型（Model-View-ViewModel）

的確，時下流行的就這三種常見的Presentation模式（這三種模式又衍生了很多變種），從根本上說這些模式是為了解決如下的幾個問題：

1，邏輯與UI緊密耦合，更換UI上的顯示往往需要更改很多邏輯程式碼，正所謂“牽一髮而動全身”。

2，應用程式狀態的維護，主要包括狀態 (State) ， 邏輯 (Logic) ，同步 (Synchronization)耦合太緊。

3，不能使不同的UI共享相同的邏輯（複用問題）。

4，要測試使用者介面效果，你需要做複雜的UI測試。

5，團隊協作不能充分發揮，因為耦合太緊的關係。

6，維護比較困難，這也是由於耦合緊密且沒有完整的單元測試。

　　之前的C/S（WinForm）和B/S（ASP.NET/ASP.NET MVC）我們已經習慣了MVC和MVP模式，現在針對WPF和Silverlight的具體特徵——它帶來了3D、動畫、音訊、視訊……這導致了UI的變化將更加細節化和可定製化。同時，在技術層面上，WPF和 Silverlight也帶來了諸如Binding、 Dependency Property、Routed Events、Command、Attached Behavior（依賴屬性體系間接實現）、DataTemplate、ControlTemplate等新特性。我們怎樣才能立足於原有的技術框架並把WPF/Silverlight的新特性揉合進去，以應對客戶日益複雜且多變的需求呢？那麼MVVM模式就是一個不錯的選擇，詳見如下框架圖：

                                             圖1

　　在MVVM模式中，你需要一個為View量身定製的model，那麼這個model實際上就是上圖ViewModel。ViewModel包含所有UI所需要的介面、屬性和命令，這樣只需要通過Binding使他們進行關聯，就可以使二者之間達到鬆散耦合，所以這樣一來，UI就可以由UI專業人員用Design和Blend來實現（當然很多效果還是需要用傳統的製圖軟體，所以我們都稱這種想法叫理想狀態），程式碼人員也可以專心寫他的邏輯和業務程式碼，所以這樣分工和協作變得更輕鬆、更愉快了。更漂亮的是View完全可以由（Unit/Automatic Test）所取代，所以單元測試也變得相對簡單。這對於我們的開發人員和測試人員無疑是一個很好的解脫，同時也提高了系統的可測性、穩定性和維護性。資料繫結系統同時也提供了標準化的方式傳輸到檢視的錯誤驗證和輸入驗證（但是個人覺得不是很好用，所以我們在實際的專案當中會寫一套自己的驗證框架）。

講到這裡，我們這裡不得不引入下面這幅圖，我覺得它能闡述一些比較重要問題：

上面的這幅圖表達了幾個概念：

1，Domain Model 始終是應用程式的核心，必須投入大量精力，按照面向物件的分析和設計 (OOAD) 最佳做法進行設計同時按照OOP進行開發。

2，Model、View 和 ViewModel 層之間實施嚴格的分離，也強調了它們之間是一種鬆散耦合的關係。

3，每一層或者每一個模組都有自己完整的單元測試，這樣即提高了程式碼質量，同時也增強了穩定性和可維護性。

4，不要為了MVVM而MVVM，不要強調UI端不產生一句後臺程式碼而把所有程式碼都扔進ViewModel，因為有的操作如果不參與邏輯流程，放在UI端處理會更好，這也符合UI和邏輯隔離的最終原則。

　　當然使用這個模式的時候，我們還要注意很多細節，這個是我們必須面對的，比如我們怎麼實現View和ViewModel關聯、View和ViewModel如何通訊、ViewModel與ViewModel如何互動、ViewModel和Model之間的弱關聯、怎樣用 Attached Behavior實現特定命令操作、怎樣彈出UI、怎樣實現導航、Validation的自定義設定、非同步呼叫、延遲載入、效能優化、與傳統技術的互動等等問題。

八. WPF團隊協作

　　前面我們講了WPF的開發模式，針對不同的開發模式，團隊協作也會有一些具體的改變，不管是MVC、MVP還是MVVM，無疑都強調的是Presentation，所以我們的域模型和底層操作都不會有所變化，或者嚴格一點的說是隻能影響到服務層/域模型之上的操作！如果不考慮多系統分散式、ESB及SOA體系，就可以分成以下六種角色：

1. 專業美工人員：整個系統的基調與樣式、頁面佈局圖、頁面效果圖、頁面的樣式與顏色、常用按鈕圖示、常用圖示圖片等等。

2. XAML人員：Style，Template，Trigger，Resource用XAML程式碼書寫，另外強調和美工及ViewModel人員的互動與合作。

3. ViewModel ：主要封裝領域模型暴露的介面，然後提供給View，所以這裡強調UI和領域模型的一個適配作用。

4. 領域模型（核心）：應用程式的核心，必須投入大量精力，按照面向物件的分析和設計 (OOAD) 最佳做法進行設計同時按照OOP進行開發。

5. 框架+常用功能開發人員：這裡就包括MVVM框架的開發、維護以及擴充套件，同時還包括資料底層訪問、日誌、異常、常用功能等。

6. 資料庫開發和管理人員：資料庫庫表的建立及維護、資料庫指令碼的建立及維護、資料庫優化以及日常的資料操作問題。

當然在開發中，這六種角色也並不是完全分離的，可以根據具體需求進行調整，同時也可以根據專案的功能劃分模組，總之選擇專案最合適的協作方式就行。

九. 瞭解並使用MVVM框架

1，到底有哪些開源MVVM框架？

　　前面介紹了WPF的基本概念和一些相關知識，我們瞭解到開發WPF應用程式可以使用現成的框架和模式，最為合適的莫過於時下正熱的MVVM模式，所以這裡我們也列出針對MVVM模式的已有開源框架：

                                             圖3

　　上面除了WPFToolKit和MEF之外都是一些常用的MVVM框架，連帶自己開發的一共是八個，所以自己也取了一個響亮的名字——MVVM八大框架！聖殿騎士本人實際專案中只用到了三個框架，之前WPF使用過MVVM Helpers，在Silverlight專案當中用過MVVMLight+MEF，後來就一直使用自己開發的框架，其他框架也研究了很長時間，但都是為了開發MVVM框架借鑑之用。框架雖然眾多，但萬變不離其宗，通用功能如下：

1，Model、View 和 ViewModel之間的關係：View和ViewModel如何關聯起來（IOC）以及如何通訊（通常採用Message），ViewModel和Model之間的弱關聯（通常採用介面或者簡單注入）。

2，事件驅動模式在MVVM模式採用Command和Attached Behaviors的形式。

3，屬性及ViewModel的NotifyPropertyChanged處理。

4，提供完整的單元測試，這也是保證框架的穩定性和維護性的保證。

　　也許有一些朋友會問我為什麼要研究這麼多框架，其實做專案只需要認真研究並實踐其中一個就行，研究它們的原因則主要歸功於自己開發MVVM框架的需要。下面就讓我們來看一下具體有哪些MVVM的開源框架（具體到每一個框架後面有時間再闡述，一篇文章寫得確實很累）：

2，最強大且功能最多的組合框架——Prism

開發者：微軟patterns & practices團隊

是否支援Silverlight：是

學習資料：Composite Application Guidance for WPF and Silverlight - May 2010.chm以及Quickstarts和StockTraderRI等。

原始碼截圖如下：

                                             圖4

　　Prism——之前又叫Composite Application Guidance for WPF and Silverlight，它是構建複雜的基於WPF/Silverlight企業級應用的主流框架。Prism中有幾個比較重要的概念：

1，BootStrapper：應用程式切入點，繼承Prism的UnityContainer或MEF提供的MefUnityContainer，為系統提供一個容器。

2，Shell：它是一個外殼，通過UI元素和Region佈局頁面。 它是應用程式的頂級視窗，顯示的內容一般就由View來填充，Shell本身並不知道它包含了哪些內容，所以功能則是由各個Module來具體提供。

3，View：它等同於MVP模式、MVVM模式中的View。可以通過IRegionManager注入到Region中。

4，Module：可以把一個大專案拆分開來，每一個Module都包含View、資料、模型，主要用於實現複雜業務操作。

5，IModuleManager：主要用於管理模組載入，可以實現動態載入。

6，IEventAggregator：事件處理介面，實現訂閱和釋出模式，這也是MVVM框架的一般做法。

　　Prism是一個比較龐大的組合框架，4.0引入MEF及功能調整以後變得更加強大了，現在可以說是組合框架和應用框架的統一體，而且是微軟團隊的力量，所以選它是值得保證的。

3，最強大且功能最多的應用框架——Caliburn

是否支援Silverlight：是

學習資料：我主要參考專案例項、原始碼、單元測試用例、國外一些部落格和社群。

原始碼截圖如下：

                                             圖5

Caliburn中有幾個比較重要的概念：

1，在Actions基礎上的Commands帶有很多功能，其中包括多引數、過濾操作以及非同步呼叫。

2，窗體和控制元件的生命週期事件也處理得比較好（包括activation、deactivation、shutdown等）。

3，不管是整個框架還是基於這個框架的應用程式的可測性都比較好。

4，提供了很多常用功能，這些在專案當中都比較有用。

5，除了支援MVVM模式之外，還很好的支援MVP模式以及其他的一些變種模式。

6，強大的依賴注入框架以及AOP框架，這裡可以靈活選用其中一種。

Caliburn是一個非常強大的MVVM應用框架，對很多功能都提供了靈活且多種實現，不論是專案使用還是研究程式碼，感覺都受益頗多。

4，輕量級且適用的MVVMLight

是否支援Silverlight：是

學習資料：除了online documentation，我主要參考專案例項、原始碼、單元測試用例、國外一些部落格和社群。另外這三篇文章非常不錯，用MVVMLight開發了一個比較完整的Silverlight企業專案

原始碼截圖如下：

                                             圖6

MVVMLight中有幾個比較重要的概念：

1，RelayCommand:通過對Command進行封裝，使得MVVM模式在WPF和Silverlight上更加容易。你只需要在ViewModel中定義好各個RelayCommand,然後在View中通過Command來繫結ViewModel中定義好的RelayCommand，就可以實現像WinForm、ASP.NET事件一樣的效果，只不過這裡是解除了UI和邏輯的強耦合。

2，Messager：MVVMLight中的Messager作用比較大，前面講了MVVM模式解除了ViewModel和View的強引用，那麼它們如何來進行互動呢？就是靠它來讓ViewModel和View來進行通訊的。一般我們會定義一個靜態AppMessages類來作為通用的一個通訊類，原理就是釋出訂閱模式。

3，EventToCommand：這裡就比較類似於附加行為的概念，是在MVVM Light Toolkit V3中開始引入的概念。

4，ICleanup介面：當顯示某個View時，需要先呼叫Cleanup方法清除資料，這也是由於ViewModel和View的耦合隔離產生的一些必要操作。

　　MVVMLight是一個非常好用的MVVM框架，提供了VS和Blend的模板及智慧感知。它結合MEF使用真的感覺很輕量級且高效，而且提供了WPF和Silverlight的支援，尤其在Silverlight的支援上比較好，所以一般選擇輕量級的Silverlight MVVM模式，它比較被看好。

5，功能齊備且易用的MVVM Helpers

是否支援Silverlight：否

原始碼截圖如下：

                                             圖7

MVVM Helpers又叫JulMar MVVM Helpers + Behaviors，其中有幾個比較重要的概念：

1，提供了MVVM模式的基本功能，包括ViewModel、View及Model之間的隔離，另外還提供了一些常用功能。

2，ViewModel的建立使用標籤的形式注入，現在也可以引入MEF。

3，IOC/DI的支援，屬性都有驗證機制，Wait Cursor的支援，當使用完viewmodel之後能及時釋放，這樣避免記憶體洩露。

4，提供了常用的Attached Behaviors支援。

5，訊息機制的引入，避免強引用產生的耦合。

MVVM Helpers是一個非常適用的MVVM框架，尤其是提供了MVVM常用功能+MEF+Attached Behaviors，所以專案中的問題基本都能解決。

6，功能強大且輕巧的Cinch

是否支援Silverlight：否

原始碼截圖如下：

                                             圖8

如果仔細研究其程式碼，你會發現它和上面講的MVVM Helpers有很多相似的程式碼，估計是相互參考了一番:-D。Cinch 中有幾個比較重要的概念：

1，這個框架在沒有MEF出現之前就已經實現了ViewModel和View之間的強引用隔離，它既沒有一般IOC的配置，也沒有IView來做中轉，並且窗體和控制元件的生命週期事件也處理得比較好，所以在這方面來說是非常不錯的。

2，提供了常用的Attached Behaviors支援，另外也提供了一些MVVM常用功能。

3，DI/IOC使用Unity實現，多執行緒的實現，避免系統出現不可預料的錯誤。

4，當使用完viewmodel之後能及時釋放，這樣避免記憶體洩露，驗證機制的加入，常用導航實現。

5，訊息機制的引入，避免強引用產生的耦合。

Cinch 是一個非常強大的框架，尤其是它比較著眼整個應用程式的搭建，所以也比較受到青睞。

7，功能簡單且易擴充套件的MVVMFoundation

是否支援Silverlight：否

原始碼截圖如下：

                                             圖9

MVVMFoundation中有幾個比較重要的概念：

1，Messenger:這裡主要用在各種不同的ViewModel之間通訊（比如相互關聯的ViewModel、主從ViewModel等），當然也可以擴充套件成ViewModel與View之間進行通訊。

2，ObservableObject：這裡相當於ViewModelBase的概念，每一個ViewModel繼承自該類，呼叫完成之後立即釋放，防止記憶體洩露。

3，PropertyObserver：主要是對INotifyPropertyChanged.PropertyChanged進行封裝，這樣封裝可以精簡程式碼，同時可以防止不當操作引起的記憶體洩露。

4，RelayCommand介面：封裝command的宣告，包括execution執行邏輯,可選的can-execute邏輯等。外部只需要例項化並Binding就可以簡單使用。

MVVMFoundation是一個非常簡單的MVVM框架，如果你覺得研究原始碼比較困難，就可以先從這個框架入手，程式碼簡單而且精煉。

8，附加：支援外掛式的依賴注入MEF

原始碼截圖如下：

                                             圖10

9，如何充分利用這些框架

　　上面我們已經介紹了七大MVVM框架+支援外掛式的依賴注入MEF，其實另外這三個框架WPF Application Framework (WAF)、Calcium、CoreMVVM（Basic MVVM framework）也很值得研究，由於時間和精力的關係，針對這三個框架聖殿騎士也沒有進行仔細的剖析，只是粗略看了一下基本功能。

其他一些框架諸如Onyx、nRoute、Nito MVVM、Ocean、GoodLight就沒有太多關注，有興趣的朋友也可以選擇其中某一個或多個框架作為研究和學習，不過還是推薦研究主流的框架，畢竟這些主流框架的開發團隊和成熟度都比較強。

上面看到了這麼多MVVM框架，那麼我們應該怎麼去學習和使用呢？簡單來說可以歸納為以下幾句話：

1,根據具體的專案選擇適合的框架，團隊和專案有大有小，所以得根據這些來選擇具體的框架，其實終歸來說，幾個框架功能都比較類似。

2,框架不用研究太多，只要適用於專案就行，尤其是熟練使用並根據其提供的TDD測試程式碼追溯其原理。

3,框架不是萬能的，對於某些應用和功能可以對框架擴充套件，這也開源最大的好處之一。

針對框架的研究，自己也總結了幾點：

1，首先看框架的相關介紹，瞭解相關的背景、功能、架構圖以及其他一些相關資訊——認識瞭解。

2，根據介紹檢視並除錯框架所提供的例項——熟悉功能。

3，自己寫一些相關的專案，主要是熟悉該框架，如果說要急於做專案，後面就可以把框架引入到專案當中——具體使用。

4，根據該框架提供的詳細單元測試研究其原始碼，這也是我最喜歡研究這些開源框架的原因——原理剖析。

5，通過上面的步驟認真分析其原理及細節——準備重現。

6，自己也根據之前的思路重複開發這個框架，最好能用TDD——框架復原捷徑。

　　上面我們談了一些開源框架相關知識，下一步我們得自己開發一個MVVM框架，一方面是對知識的總結，另一方面也是對知識的再提煉，同時也能使自己的認識提升到另一個高度，緊接下文。

十. 自己開發MVVM框架

　　由於之前自己做了一套框架，但是還沒有趨於完善，所以暫時不準備共享出來（主要是WPF和Silverlight版本更替比較頻繁且沒有加入模板及智慧感知）。對於開發一套MVVM框架，具體需要做一下幾個操作：

1，要能解決Model、View和ViewModel之間的強關聯，這也是核心功能，尤其是View和ViewModel，不管是使用IOC Container還是MEF都行。

2，命令和附加事件的處理，對Command進行封裝，滿足多引數、方法過濾、泛型、非同步回撥等，對附加事件進行封裝，使它像使用命令一樣簡便。

3，由於View和ViewModel是弱關聯或者是無關聯，如何讓它們進行通訊？這就需要加入Messenger機制。

4，前面引入了訊息機制（一般是靜態化處理），如何來管理、例項化、清除訊息呢？這裡得建立一套訊息機制。

5，由於前面採用了弱關聯或者無關聯，並且引入了訊息機制，所以需要對操作有日誌記錄，否則出了問題無法快速定位及追查原因。

6，如何統一管理ObservableObject、PropertyObserver等這些物件呢？所以得自己建立一套變更體系。

7，對常用功能及操作進行封裝，提供一些常用類庫以及UI Helper等。

　　總之，開發MVVM框架不能求全，只要適合專案就行，也不要想一次就能完善整個框架，在使用時不斷根據需求擴展才是明智之舉。另外附加三點開發MVVM框架心得：

1，充分借鑑其他開源框架，研究各個框架的不足和優勢，然後把思想貫穿於自己的框架中，當然有些常用功能程式碼也可以直接借鑑過來。

2，對於這樣一個比較龐大的框架，使用TDD+反覆重構無疑會提高開發效率，同時也能提高框架的可維護性和穩定性，這也是團隊使用的一個前提。

3，框架會使用一些常用設計模式，有了它們可以讓框架更具有擴充套件性，同時也減少了開發成本、增加了可維護性。比如觀察者模式（訊息的釋出、訂閱、觸發）、中介者模式（直接通訊的類轉化為中間類來處理，隔離耦合）、外觀模式（提供一個簡單的接口出來，在內部進行大量的封裝，這樣就可以起到易用且功能強大的目的）、裝飾模式（原來已經穩定的功能模組，如果在不改變原有結構的基礎上進行擴充套件，無疑這是一個很好的實踐）等。

總結

　　上篇WPF企業內訓全程實錄（上）主要講解歷史淵源、概念引入、基本闡述以及WPF的每個知識點。這篇主要主要圍繞WPF開發模式、WPF團隊協作和MVVM框架三個議題進行闡述。下篇將著重強調結合其他技術共同打造WPF專案、相關效能優化、以及部署與更新問題，所以敬請期待！另外如果有不懂的地方也可以參考之前寫的WPF 基礎到企業應用系列，最後宣告一下，由於聖殿騎士才識淺薄，所以以上觀點只是個人的看法與心得，遺漏和錯誤之處也敬請海涵。懷著技術分享與交流的態度分享出來，希望各位多多指教！