WPF老矣，尚能飯否——且說說WPF此生將來（下）：安心

時間 2019-12-10

標籤 wpf 尚能且說此生將來安心简体版

原文原文鏈接

在前面的上、中篇中，咱們已經能夠看到園子裏朋友的點評「後山見！ WPF就比winform好！激情對決」。看到你們熱情洋溢的點評，作技術的我也很受感動。老實說，如何在本文收筆--WPF系列文章，我很緊張；我但願你們閱讀完本系列文章後：各取所取、盡興而歸。坦白的說，葡萄城做爲一家專一.NET技術的公司（僅海外分公司之一的西安葡萄城已經成立26年），咱們幾乎走遍了微軟的技術路線，不管從技術前瞻性、或是技術深度均有涉獵。咱們作控件的，也是很是想知道WPF將來走勢如何。html

但抱歉的是，我沒法預測將來WPF會怎麼樣：數據庫

WPF to die? or not to die！編程

我只能在本篇收尾披露葡萄城Spread Studio系列產品技術研發路線，與你們共勉：windows

you can't connect the dots looking forward;設計模式

you can only connect them looking backwards.安全

---------摘錄一段喬布斯在哈佛大學的演講詞。網絡

有理由安心

在前面的2篇中你確定認爲我在「黑」微軟，而事實上這確實是在「黑」微軟。可是事物都有兩面性，「黑」完了，也得誇一下，再就是給你們分享一些微軟積極和改進的WPF地方，咱繼續……架構

還是活躍的團隊

根據Greg Levenhagen的文章信息（WPF已死？——不，沒死）得出目前仍然有一個開發團隊專一在WPF的開發工做上；但Greg沒有確切的說明具體數字，所以不能明確的衡量這個團隊的做用。
可是很明顯的一點是：微軟沒有放棄這一項億萬人使用的技術，仍然有專職開發團隊而不是合併到其餘團隊裏。這已是一個好消息了。
另外從Greg的信息裏得出，這個團隊不只是在維護已有的版本，同時還在積極準備着手下一個版本的開發工做（會是WPF5嗎？）。固然在沒有給這個版本的變動說明的狀況下，咱們很難保持樂觀，由於極可能它只是一個漏洞修復和性能調整，沒有主要功能。框架

仍在開發中（2014-11月更新）

在2014年11月WPF團隊發佈了一篇新的文章——WPF路線圖（The Roadmap for WPF），代表WPF仍在進行開發。該團隊的工做重點是修復主要的問題，好比性能，這個從WPF一開始就帶着並已持續修復加強的問題點，另外還有和Visual Studio開發套件深度集成等等點。
或許另外一個更重要的是徹底支持觸摸設備和高分辨率設備，代表微軟聽到了社區的聲音並採起了相關的措施。mvvm

新版本的工具

我注意到另外一個在官方工具這邊的正面的信號，Prism，這個由一些列工具和開發XAML程序的最佳實踐組成的產品，隨着WinRT的版本升級也已更新到版本5.0，同時也是爲WPF提供的一個新版本。
正如第一部分前文所說，官方的WPF Toolkit已經停了，而另外一個項目接過了接力棒，它就是Externded WPF Toolkit，一個由著名的第三方擴展提供商Xceed開發的項目。所以，從一個WPF開發專家（同理能夠是其餘的Windows技術）角度來看，這是一個由一系列控件組成的內容豐富的合集，更重要的是它還在開發着，最新的更新是2014年7月，也就是寫本文的三個月前的事。
最後還有兩個上層MVVM框架庫，MVVM Light Toolkit和Caliburn.Micro，也是活着的，最新版大約三個月左右。
所以WPF的工具生態系統仍是活着的，並持續演進進化着，對於企業來講這太使人欣慰了，由於不會留下一堆不可維護的項目而發愁了。

管理層的改變

在2012年底，當時的Window部門的總裁Steven Sinofsky離開微軟。爲何說這是給WPF的一個正面信號呢？由於Steven Sinofsky是一個完全的.NET反對派，而且和其餘團隊搞很差關係（或許這是他離職的主要緣由）。這也能夠片面的反映出爲，並不是因爲一些技術緣由，致使.NET技術沒有在下一代Window中做爲基礎存在，雖然這個微軟創立的技術業已軟件開發的重要部分之一。從外部來看，很難評估出在Window 8+中Steven Sinofsky的真實感覺和在設計決定中所起的影響。

操做系統市場保守性

另外一個WPF的有利消息是，事實上不管公司和我的都不會當即遷移到最新的操做系統，其中有一堆的理由：好比太花錢，好比太費時間，好比風險太大。
實際上遷移到最新的系統確實是一件使人望而卻步的過程，由於須要保持應用程序的兼容性：這包括那些外部供應的，譬如微軟辦公套件，還有一些內部團隊開發的部分。從我我的經驗來看，這些軟件的構建，會輕輕鬆鬆耗掉兩年多時間。
當前（2014年中）在PC市場份額中的WinRT所佔比例顯得特別落魄：

Windows 8 + 8.1 : ~15%
Windows 7 : ~55%
Windows Vista : ~5%
Windows XP : ~25%

所以PC市場超過80%的設備不能使用WinRT，除了WPF以外別無他選。另外在某些領域對於Window 8+來講更糟：在我所知的法國公司裏，財務這一塊對其採用率是零，幾乎全部的都沒有完成向Windows 7的遷移，甚至其中我所知道的很多仍使用Windows XP，由於安裝應用對他們來講不是問題。

考慮這個更新換代過程將大約有五年時間，在此期間，WPF將是大量應用的惟一選擇。

應用程序生命週期保守性

你應該知道要遷移一個應用是很費事的：首先你得參與一些列會議並學習對業務的影響，還得在合適的時機努力的把各類「可控的風險」擺到檯面上，而後經過新的應用一一搞定，同時還得保證不能有反覆。一般在完成完整的切換過程以前還得保證新的和老的應用能同時工做；更甚你還得呼叫數據庫團隊來遷移數據，網絡團隊來更新防火牆規則……
這就是爲何企業應用程序直到有合理的業務緣由纔會作遷移的緣由，而新技術不是問題，所以，不少現有的WPF程序會停在這裏，這意味着WPF技能在能夠預見的未來仍然有需求，你只須要看看大量現有的和新開始的WinForm應用程序就能夠明白，雖然WPF從2006年就開始替代它。

從技術角度來看，WPF和WinRT是很類似的，可是不徹底兼容：仍然有不少的功能在WinRT 8.1中沒有或者不一樣，譬如在WPF中可使用clr-namespace去映射一個命名空間到XAML中，到WinRT中，這就是XAML兼容問題，讓人感受如履薄冰。

WPF很成熟

很明顯WPF的開發支出顯著降低，這看起來值得擔憂。

可是據個人經驗看來，每個開發人員都有相似的經歷：初版開發工做量巨大，後續的發佈就會從社區反饋得到好處，最後只須要很小的維護工做。
這確實是WPF自第一次發佈（WPF 3.0（我我的看到的更早的Beta）和WPF 3.5）以來爲windows應用程序開發指明的路線；而後WPF 4.0又從工具包（WPF Toolkit）裏移過來一些控件，像DataGrid，同時作性能提高，到最後WPF 4.5引入了Ribbon同時依然作性能提高。
成熟的技術只須要更少的開發支出，通過八年時間，WPF已經很成熟，其新功能和bug修復都已經大大減小。到現在WPF能夠說已經進入維護狀態，在它的生命週期裏，已經不須要「奮發圖強」式的作加強開發了。

業務線生態

若是說在某個領域WPF作得很好並一直閃耀的，那必定是業務線（Line Of Business）應用。
首先大部分專家都是基於.NET作開發，由於它是一個成熟的平臺，同時不少公司在Windows平臺上開發他們的業務線應用，這些確定不會被拋棄，而是儘量的被重用。
還有不少以.NET爲中心的工具在WinRT下不可用，例如，對象關係映射（ORMs）中得NHibernate或者Entity Framework，而這些偏偏業務線應用訪問關係數據必不可少的組件。
其次，一些大型的業務線應用像交易平臺，根本不能從WinRT平臺得到好處，由於根本就不須要，甚至限於安全性和移動性，壓根就不想要。所以像這一類大型應用一度反對微軟WinRT應用的設計規範和指導：他們只想在屏幕上顯示最小集合的數據！

學習曲線

若是你是一個經驗豐富的WPF開發人員，能夠說超過80%不須要再學習就已是WinRT開發人員了，若是你是業務專家，那麼80%的經驗能夠直接應用到WinRT程序中。

緣由就是用來開發WPF應用的大部分基礎工具和WinRT是同樣的：

同樣的編程語言：C#，VB.Net……
同樣的標記語言：XAML
同樣的方式關聯視圖和數據：數據綁定（Data binding），數據模版（DataTemplates）……
同樣的設計模式和實現：MVVM，INotifyPropertyChanged, INotifyCollectionChanged, ICommand……

所以你在其餘基於XAML平臺好比WPF和Silverlight的投資能夠延續到WinRT上，並縮減學習曲線的陡峭度（還記得當初仍是一個學習WPF的新手嗎？）

WPF內容豐富

WinRT不是一個WPF的克隆，其中不少的功能都沒有實現，所以若是你只是開發桌面應用程序，從技術能力來講WPF是一個更好的選擇。可是我把它放在最後一條，由於就我我的而言，我以爲這並不很是重要，WinRT還一直在向前演進，它們之間的差距將會愈來愈小，可是我仍然猜測一些開發人員不想在WinRT上開發，而是想要WPF。
再次說明WinRT的附加值不是在其本質上得技術加強，而是在開發模型上提供了移動平臺開發能力和部署到微軟商店的能力。

將來戰略

不管你是企業開發仍是我的開發，你都應該考慮減緩對WPF的技術投資，轉而培養在WinRT方面的專長。

業務

在業務方面，由於有一些老版本的Windows，包括Windows 7，因此確定不能中止你的WPF開發工做。對於那些已經存在的應用，也不用擔憂，沒有必要要遷移到WinRT，除非你想要得到新的能力或者和微軟商店兼容。能夠預見不久的未來微軟會對WPF作支持的，對於微軟來講，向後兼容是一件很重要的事情。舉例來講，雖然已經很難在最新的Windows裏創建VB6的環境，可是你仍然能夠作到，所以你的應用包括安裝都會一直能平滑的工做。
根據你的可用的工時，你應該把時間專一到技術潛力上，同時讓一些開發人員開始認真的考慮一下WinRT：如何從中得到好處，尤爲是在開拓用戶方面；新的應用將如何開發；如何重利用已有的工具和代碼；什麼是要關注的潛在問題……
作一個應用，要想從爲手機和平板設計的WinRT中獲得好處，得須要先制定好遷移路線，很明顯的緣由就是WinRT中缺失了不少WPF種的許多功能。從概念設計開始就應該驗證新技術在你的情景中適用度。

開發

做爲一個開發，咱們不但願咱們的技術技能是沒人要的，而是創建足夠強大的技能組合體以知足更多的業務和項目，以此下降被技術拋在後面的風險。所以，做爲一個經驗豐富的WPF開發人員，就我我的經驗，你應該在選擇繼續強化你的WPF技能或者轉向得到WinRT開發技能之間選擇後者。
或者你能夠繼續在WPF領域等待直到市面上稀缺WPF開發，就像現在的COBAL和VB6這類老技術同樣，可是我估計還得等十年。由於隨着IT業的發展，任何技術在市場上都會有不少的開發人員，尤爲是像WPF這樣的主流技術，因此我是不期望這個。
可是也沒必要面對第n個冒出的新技術而今後意志消沉，這就是咱們這個行業的商業模型：它須要無時無刻的創造新事物（還記得SOA爲各大IT公司，他們的僱員、股東和承包商賺了大筆大筆的銀子嗎）來賣給客戶，就像蘋果公司（Apple）的iPhone系列，從iPhone 1，2，3……到現在已經6了，估計不久未來就42啦，但這就是它的工做模式。慶幸的是做爲開發商的咱們，在衆多的壁壘上有咱們的優點，咱們輕鬆以此爲生，客觀的說，這些新技術豐富了企業和我的的生活。

結論

綜上所述，我認爲這些事實是很清楚的：WPF過去輝煌過，現在還在用，在不久的未來會和WinRT會直接競爭，可是當WinRT得到更多投入和足夠的市場份額以後，WPF就會像現在的VB6和WinForm同樣被棄用。
重要的是咱們不能否認，有些事情確定會發生，不可避免的在腦子裏產生悲觀情緒。不要期望WPF還會復興，在IT界確定不會發生（固然了，COM能夠說是藉着WinRT之體復出），客觀上講，WPF沒有在趨勢和新事物上作任何量身定製的亮點。
固然，前途不是一片灰暗，WPF不是已經消亡和過期，或者正在死亡和棄用，它只是剛剛達到頂峯，當企業基礎架構遷移到Windows 8+以後，將來的開發就會選擇WinRT，那是WPF就會慢慢淡出。
請保持務實和透明：在WPF能給你的客戶帶來價值的時候使用它，可是得透露出相關因素，並幫助他們爲未來作好準備。我已經在個人WPF培訓的教材中交叉串入一些WinRT的內容，包含了一些簡要總結來闡述這些事情，並根據它們的重要性將它們一一突出。
可是就我我的而言，我以爲也不該該在WinRT作過多的投入，爲何呢？由於隨着對WinRT攝入愈來愈多，我感受好處正在一點一點減小：

若是你是一個業務線應用，你的惟一目標是Windows桌面，同時還得兼容Windows 8以前的系統，至少Windows 7，因從WinRT顯然不是一個選項，你還得用WPF；
若是你面向平板和手機，請不要忘記，市場上得90%以上的份額是iOS和Android，因此WinRT壓根就不是問題，此時你該選擇使用網頁技術（Javascript/HTML/CSS）或者像Xamarin（C#)或者QT（C++)這樣的本地跨平臺框架，就是說，大部分場景WinRT毫無用武之地。此外，應該知道微軟正投入巨資在研究後續技術，此時提問是否WinRT已死還爲時尚早，可是若是試圖把WinRT做爲主流的開發平臺，我確定會大吃一驚。

在我看來，WinRT是一個僅適用微軟內部使用的良好平臺，由於它能夠很好的在不一樣的Windows系統層面上作代碼共享，模仿蘋果（Apple）的工做模式；可是對於最終開發人員來講，WinRT是一個很是有限的方式：在PC、平板和手機間共享代碼但卻只適用於Windows系列設備。或許不少業務其實只須要其中一個，可是我仍懷疑這一點，由於現在的應用一般是由員工我的提供設備（BYOD），它能夠是任意設備，很大多是iOS或者Android。

[完。]

完整系列文章目錄：

---------------------------------------------------------------------------------------------------------------------------------