雖然WPF再也不更新了,可是基於WPF的技術仍是在發展着,就好比如今的WinRT,只不過API換了一套而已,xaml仍是xaml,數據綁定仍是數據綁定,依賴屬性仍是依賴屬性,模板仍是模板。其實學過WPF的轉WinRT仍是比較爽的,Blend的操做也沒變,只不過如今WinRT的人才需求量的確有點坑。
最後感謝WPF給咱們帶來MVVM這種開發方式、開發模型。 by @h82258652html
雖然winfrom自己中止更新,可是工具卻在一直升級啊!好比說VS設計器,C#語法,第三方控件和開源組件等等。
另外,WinForm基於Win32 api的設計自己就很成熟,從內容上來講基本上已經一應俱全,微軟不更新也不會有問題。 by @winkingzhangapi
技術老是要更新換代的,有些人說換個API來賺錢,倒也搞笑,映射出好多人換個API就不會開發了。我倒以爲,人家更新歸更新,咱們開發者作的其實永遠就一件事情,寫好咱們的代碼,作好的產品。.NET的代碼永遠也就那樣寫,對吧。 by @筍乾瀏覽器
在2014年二月,微軟任命了一個新的CEO,他就是薩提亞·納德拉,來自微軟雲服務部門。
他將接替上任史蒂芬·鮑爾默,就是那位不懂移動市場的(首先是iPhone和Android),甚至多是微軟和競爭對手(蘋果和三星)市場之爭中敗北的緣由之一。安全
和他的前任相反的,薩提亞·內德拉爲微軟肯定的全局目標是「雲優先,移動優先」,所以要從跳出經典的桌面市場,這確實是一個合情合理的策略。可是準確的說,WPF是一個從「老」模型上設計出來的:這是一個典型的富桌面應用;與之相對的WinRT採用一個徹底不一樣的設計模型,更加貼近移動平臺需求。
固然了,桌面和單機市場並無死亡,可是顯然再也不是獨挑大樑。服務器
爲了獲取部分應用程序開發商的年收入,像蘋果和微軟這樣的衆多平臺供應商都建立本身的「商店」,全部的發佈和購買都在此。據我所知,很不幸,微軟商店的應用程序必須是基於WinRT開發的,所以WPF開發的應用是不能發佈到這個商店裏。
注意到對於一些業務相關的應用是內部使用和部署的,或者大型的應用程序開發商好比作ERP系統的,他們有本身的分銷渠道,所以這都不是問題;可是對於一個小型開發商來講,它就是問題了,由於你但願利用市場的透明性來保證在其餘競爭對手以前搶佔到市場。
愈來愈多的人在不知道從哪裏得到一個新的應用的時候本能的選擇使用在線商店的搜索功能。若是你開發一個WPF應用程序,你將很難發佈產品,更不用提銷售就更難了,所以,用WinRT開發吧。框架
若是你天天經過移動設備上的瀏覽器或者本地應用程序獲取數據,那麼你確定懂得現在市場上的潮流趨勢:你的應用須要移動版本!
WPF壓根就不是一個爲移動開發的主角,甚至配角都算不上,前幾年,爲Windows Phone定製的Silverlight一度亮相,做爲當時的Windows Phone 7的開發工具。可是一個平臺一套開發套件顯然不是好主意,儘管能夠共享一些過程和標記代碼。
WinRT正是爲此問題而誕生,由於它是一套爲Windows 8+全系列平臺設計的,從系統級別考慮一致性的,易於上手開發的通用工具集。其中有一些第三方控件支持WinRT,如:ComponentOne Studio for WinRT XAML。工具
若是你這些年一直在微軟技術平臺工做,那麼你確定知道微軟花錢很謹慎,一個很好的緣由是,首先,做爲一個公司,得賺錢,還得比股東要求的更多,因此,能省則省吧;其次,不少看起來彷佛很小的一個小功能實際上有不少的工做去作,Eric Lippert在他的博客裏作了很生動的闡述:How many Microsoft employees does it take to change a lightbulb?
所以,當社區提起要修復一個bug或者一個新功能的時候,僅當它是相似下面兩條這樣的一個大問題纔會被採納:
- 重大問題,好比安全漏洞,即便不多人會碰到
- 小變化可是無數人抱怨
同時開發WPF和WinRT將會暗示同時處理兩套功能需求,同時修復兩份bug,顯然這不合理,尤爲在微軟削減開支的時候。開發工具
想一想什麼是能讓WPF「存活」下來的特質呢,好比做爲可移植的技術開發客戶端應用,但很是不幸,它沒有。
已經有一個可移植版本的.NET(指學院派的,包含CLI):Mono,它能夠在Windows下運行,同時也能在Linux、Unix和Mac上運行。[注:本文未提到微軟.NET開源、可移植的最新消息]
另外,Mono不是一個玩玩而已的技術,它實實在在的工做着,就我我的,我已經在Ubuntu服務器上和Jenkins集成服務上構建應用。
Mono支持大部分的.NET框架的大部分技術,惟獨沒有支持WPF;若是我記得沒錯的話,曾經有一個項目叫「Olive」曾經作過嘗試,但沒有真正的開始,由於工做量太大了,特別是底層呈現層。
Mono支持的惟一界面是WinForm,使人哭笑不得的是,正因可移植性,WinForm才能比WPF活得更好。spa
當我做爲一個Silverlight開發人員的時候,我發現技術消亡的速度比我想象的要快得多。時光回到2008/2009年,富互聯網應用(RIA)仍是一個很響亮的噱頭,微軟爲此發佈了自家的框架,Silverlight,並在隨後的一系列微軟事件中公開亮相,但願各個業務主管在他們的IT體系中運用。隨後的2010年,直到2011年第一季度,咱們就在開發Silverlight應用。
可是隨後的某地舉行的一次技術會議上,微軟宣佈中止推動Silverlight,轉而開始推廣HTML5生態體系(包括CSS和JavaScript)。可是官方卻說Silverlight沒變化,對此我很是懷疑,也通告報道此事,然後個人團隊決定中止Silverlight開發,轉向集中精力投入「經典」的WPF開發,順帶還能得到一些好處(好比,Silverlight不是「即插即用」的,而是首先須要管理員權限安裝Silverlight運行環境。.net
值得慶幸的是,大部分的XAML和C#代碼(大約85%)是和WPF共享的,所以沒有損失太多,不須要作太多的確認咱們就停下來了。
最終這是一個正確的決定,由於到2013年微軟官方宣佈Silverlight終止,不少的IT相關人員很是吃驚,由於他們沒有收到任何前兆。
我想此類事情不會粗暴的再WPF身上發生,可是我認爲,在當今的IT環境和上下文中,你確定很失望,今後多疑,甚至徹底不信任。
[未完待續]
鑑於在《WPF老矣,尚能飯否——且說說WPF此生將來(上):擔憂 》網友們評論的特別聲明:
葡萄城最近1月發佈的Spread Studio 8和ComponentOne 2014V3、ActiveReports 9依然對WPF、WinRT、SilverLight提供產品升級和技術支持。
完整系列文章:
WPF老矣,尚能飯否——且說說WPF此生將來(中):策略