WPF 企業內訓全程實錄(中)
摘要
WPF企業內訓全程實錄由于文章比較長,所以一共拆分成了三篇,上篇WPF企業內訓全程實錄(上)主要講了基礎,這篇作為該實錄的中篇,起著承上啟下的作用,主要講解開發模式、團隊協作及應用框架。其實如果大家仔細看目錄,可以發現我安排的順序是首先講解最基本的概念和基礎內容、然后過渡到開發模式及框架、最后結合其他技術和項目實際運用,這也是學習并應用一門技術最好的流程。上篇實際上主要有兩個側重點:一則就是理清脈絡——歷史淵源、概念引入及基本闡述;二則是講解WPFBasic——主要講解WPF的每個知識點,涵蓋了WPF的方方面面;如果大家感興趣,可以下載代碼進行仔細研究,如果有不懂的地方也可以參考我寫的WPF 基礎到企業應用系列,這里受篇幅限制,就不詳細論述。今天的中篇主要圍繞WPF開發模式、WPF團隊協作和MVVM框架三個議題進行闡述,希望能給大家帶來一些參考和幫助。
章節綱要
· 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)所取代,所以單元測試也變得相對簡單。這對于我們的開發人員和測試人員無疑是一個很好的解脫,同時也提高了系統的可測性、穩定性和維護性。數據綁定系統同時也提供了標準化的方式傳輸到視圖的錯誤驗證和輸入驗證(但是個人覺得不是很好用,所以我們在實際的項目當中會寫一套自己的驗證框架)。
講到這里,我們這里不得不引入下面這幅圖,我覺得它能闡述一些比較重要問題:
圖2(注:此圖引用自Robert McCarter的MVVM一文)
上面的這幅圖表達了幾個概念:
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體系,就可以分成以下六種角色:
-
專業美工人員:整個系統的基調與樣式、頁面布局圖、頁面效果圖、頁面的樣式與顏色、常用按鈕圖標、常用圖標圖片等等。
-
XAML人員:Style,Template,Trigger,Resource用XAML代碼書寫,另外強調和美工及ViewModel人員的交互與合作。
-
ViewModel :主要封裝領域模型暴露的接口,然后提供給View,所以這里強調UI和領域模型的一個適配作用。
-
領域模型(核心):應用程序的核心,必須投入大量精力,按照面向對象的分析和設計 (OOAD) 最佳做法進行設計同時按照OOP進行開發。
-
框架+常用功能開發人員:這里就包括MVVM框架的開發、維護以及擴展,同時還包括數據底層訪問、日志、異常、常用功能等。
-
數據庫開發和管理人員:數據庫庫表的建立及維護、數據庫腳本的創建及維護、數據庫優化以及日常的數據操作問題。
當然在開發中,這六種角色也并不是完全分離的,可以根據具體需求進行調整,同時也可以根據項目的功能劃分模塊,總之選擇項目最合適的協作方式就行。
九. 了解并使用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
下載地址:http://compositewpf.codeplex.com/
開發者:微軟patterns & practices團隊
是否支持Silverlight:是
學習資料:Composite Application Guidance for WPF and Silverlight - May 2010.chm以及Quickstarts和StockTraderRI等。
源碼截圖如下:
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
下載地址:http://caliburn.codeplex.com/
開發者:Rob Eisenberg
是否支持Silverlight:是
學習資料:我主要參考項目實例、源碼、單元測試用例、國外一些博客和社區。
源碼截圖如下:
圖5
Caliburn中有幾個比較重要的概念:
1,在Actions基礎上的Commands帶有很多功能,其中包括多參數、過濾操作以及異步調用。
2,窗體和控件的生命周期事件也處理得比較好(包括activation、deactivation、shutdown等)。
3,不管是整個框架還是基于這個框架的應用程序的可測性都比較好。
4,提供了很多常用功能,這些在項目當中都比較有用。
5,除了支持MVVM模式之外,還很好的支持MVP模式以及其他的一些變種模式。
6,強大的依賴注入框架以及AOP框架,這里可以靈活選用其中一種。
Caliburn是一個非常強大的MVVM應用框架,對很多功能都提供了靈活且多種實現,不論是項目使用還是研究代碼,感覺都受益頗多。
4,輕量級且適用的MVVMLight
下載地址:http://mvvmlight.codeplex.com/
開發者:Laurent Bugnion
是否支持Silverlight:是
學習資料:除了online documentation,我主要參考項目實例、源碼、單元測試用例、國外一些博客和社區。另外這三篇文章非常不錯,用MVVMLight開發了一個比較完整的Silverlight企業項目
- Part 1 - Introduction, Installation, and General Application Design Topics
- Part 2 - MVVM Light Topics
- Part 3 - Custom Authentication, Reset Password and User Maintenance
源碼截圖如下:
圖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
下載地址:http://mvvmhelpers.codeplex.com/
開發者:Mark Smith
是否支持Silverlight:否
學習資料:http://www.julmar.com/blog/mark/以及提供的實例、源碼及測試用例。
源碼截圖如下:
圖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
下載地址:http://cinch.codeplex.com/
開發者:Sacha Barber
是否支持Silverlight:否
學習資料:http://sachabarber.net/以及提供的實例、源碼及測試用例。
- A walkthrough of Cinch, and its internals - Part I
- A walkthrough of Cinch, and its internals - Part II
- How to develop ViewModels using Cinch
- How to Unit test ViewModels using Cinch app, including how to test Background work threads which may run within Cinch ViewModels
- A Demo app using Cinch
源碼截圖如下:
圖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
下載地址:http://mvvmfoundation.codeplex.com/
開發者:Josh Smith
是否支持Silverlight:否
學習資料:http://joshsmithonwpf.wordpress.com/以及提供的實例、源碼及測試用例。
源碼截圖如下:
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
源碼截圖如下:
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 基礎到企業應用系列,最后聲明一下,由于圣殿騎士才識淺薄,所以以上觀點只是個人的看法與心得,遺漏和錯誤之處也敬請海涵。懷著技術分享與交流的態度分享出來,希望各位多多指教!