近日微軟公布了最新的WPF路線圖,一片熱議;對于老牌控件提供商葡萄城來說,這是WPF系列控件一個重要的機遇,因此,Spread Studio for WPF產品做了一次重要更新,并隨著Spread Studio 8.0發布。鑒于此,選擇翻譯并整理了一篇自codeproject的文章:《Is WPF dead: the present and future of WPF》,拋磚引玉,且聊聊程序員心目中的WPF。
引子
作為一個老牌WPF程序員,多年來一直關注的問題是,在微軟發布最新的WinRT框架之后,接下來的客戶端編程將何去何從。
顯然我有充分的理由擔心這個,眾所周知的Silverlight的中途擱淺,它對下游的開發人員帶來了很大的損害;俗話說:一朝被蛇咬,十年怕井繩。這就是真實寫照。
我從2009年開始就對WPF投入很大的精力,使用它開發財務相關的行業軟件,如今,我依然還在這里,但是焦點轉向了培訓相關工作。作為專業開發和培訓講師,WPF的將來對我來說至關重要,這也是我深入思考這個問題的根結。
本文我將本著客觀和透明的方式給大家分享我所的發現和感悟,希望起到拋磚引玉的作用,以此為社區提供更好的有前景的WPF。
另外,在本文的結尾,我將為企業和個人開發提供一些策略和個人見解。
有理由擔心
首先,我將展示那些我所擔心的標志性信號,如果你是一個WPF的利益相關者,這也會是你所擔心的。
WPF團隊博客斷更
如所有微軟的技術團隊一樣,WPF團隊也有自己的博客,主要話題集中在向社區分享團隊內部成員在WPF上的各種經驗。
該博客的最后一篇文章發表于三年前,2011年五月,或者另一個精確的說法是當WinRT宣布開始并作為下一個重大目標的時候。
一個斷更的博客會暗示很多問題,恕我直言,從來沒有好的方面的:或許這個團隊被縮減到極小,以至于博客被擠出任務優先級列表了;也可能是最優秀的團隊成員已經轉到其他項目,比如WinRT;更甚者,或許這就是團隊隱晦的給社區傳遞出來的信號……
從公共關系角度來看,一個活躍的團隊博客是很基本的點,因為它對外展示了技術發展和忠實的開發團隊向社區主動表達工作的滿意和分享的意愿。
你或許已經注意到微軟的MSDN博客其實并不活躍,為數不多的例外是EntityFramework團隊博客,這應該歸功于經常更新博文的Rowan Miller,而這恰恰就是我一直偏愛這項技術的一個主要理由:這是一個天才團隊和有責任的團隊開發出來的。
官方WPF Toolkit不再更新
WPF Toolkit是一個由微軟團隊開發的開源免費項目,目標是WPF的重要輔助套件和前哨。
一個很典型的例子是DataGrid控件,在WPF的起初的發行(WPF3.0和WPF4.0)是沒有的,但在Toolkit里面有,到后來,最終WPF4.0把它放到正式的發行里了。
官方的Toolkit一直扮演這樣的角色一直到2010年,但是自從項目開始清減之后,也就沒有什么人關注所謂的下一版本的發布了。
表現出不活躍的信號是:Google搜索引擎對關鍵字“WPF Toolkit”的排次把官方的toolkit放第二,而第三方的反倒占據第一(本文第二部分會有更細節的描述)
WPF不再進行認證考試
官方的WPF認證考試(70-511)已經不在延續,并將在2015年夏天終止。
這給開發人員一個強烈的明確信號,就是不要在該項技術上投入了,相應的可以考慮投入時間和精力到WinRT上,這樣才會從認證考試獲得回報。
或許將來某一天微軟會推遲這個認證考試的吊銷,正如他們曾經做過的,在收到大量社區開發者的訴求之后會有一定的妥協,但是都不可避免的是,WPF已經不在重要。
就我個人而言,我一直很猶豫要不要過這項認證考試,因為我實在無法保證時間和物有所值(是的,我自己付費)。反而很堅定的認為可以準備WinRT的認證考試,因為它在將來的幾年都會是有效。
不再提供Window 8+系統集成
回想WPF4.0發布,同時發布了很多的Window 7系統相關的集成和增強,比如任務欄定制(彈出列表,進度,遮罩等等……)。
但是當WPF4.5到來時,卻沒有給Window 8+系統功能做完全的集成,比如則邊欄(Charm Bar),大多數應用只能通過互操作來交互。
因此,微軟沒有投資在這些集成工作上,這很明顯的揭示WPF已經不再是Window系統的一等公民,實際上它首選投入WinRT的懷抱,個人認為這是一個合理的決策。
WPF不支持WinRT
微軟,這個曾經的老牌軟件供應商,如今業務多樣化,開始成為一個硬件供應商,效仿它的競爭者蘋果和三星。
為此微軟收購了諾基亞,以期獲得移動市場的長期席位。
在平板和筆記本這方面,為了和蘋果的iPad平板和MacBook Pro筆記本相競爭,微軟推出了Surface系列。
Surface 一代和二代根據硬件架構(x86和ARM)分成兩種版本,而后者對應有了自己的專有系統:Windows RT(不要和作為軟件層的WinRT混淆);但是Windows RT不支持(至少官方不支持)老的應用接口,比如優秀的老式Win32接口,因此也不支持在此基礎上“包裝”出來的衍生技術,像WinForm等等,當然包括WPF,因此無法在Surface版本上運行WPF應用程序。
微軟不在此投入理由很簡單,就是它想在最新的IT趨勢中去除Win32,讓量身定做的WinRT代替。
完整系列文章:
相關閱讀:
微軟 Build 2017 開發者大會:Azure 與 AI 的快速發展
文章列表
留言列表