WPF老矣，尚能飯否——且說說WPF今生未來（中）：策略 - powertoolsteam @ IT工程師數位筆記本

文章出處

本文接上文《WPF老矣，尚能飯否——且說說WPF今生未來（上）：擔心》繼續。

“上篇”中部分精彩的點評：

雖然WPF不再更新了，但是基于WPF的技術還是在發展著，就比如現在的WinRT，只不過API換了一套而已，xaml還是xaml，數據綁定還是數據綁定，依賴屬性還是依賴屬性，模板還是模板。其實學過WPF的轉WinRT還是比較爽的，Blend的操作也沒變，只不過現在WinRT的人才需求量的確有點坑。
最后感謝WPF給我們帶來MVVM這種開發方式、開發模型。 by @h82258652

雖然winfrom本身停止更新，但是工具卻在一直升級啊！比如說VS設計器，C#語法，第三方控件和開源組件等等。
另外，WinForm基于Win32 api的設計本身就很成熟，從內容上來說基本上已經包羅萬象，微軟不更新也不會有問題。 by @winkingzhang

技術總是要更新換代的，有些人說換個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活得更好。

Silverlight綜合征

當我作為一個Silverlight開發人員的時候，我發現技術消亡的速度比我想象的要快得多。時光回到2008/2009年，富互聯網應用（RIA）還是一個很響亮的噱頭，微軟為此發布了自家的框架，Silverlight，并在隨后的一系列微軟事件中公開亮相，希望各個業務主管在他們的IT體系中運用。隨后的2010年，直到2011年第一季度，我們就在開發Silverlight應用。
但是隨后的某地舉行的一次技術會議上，微軟宣布停止推進Silverlight，轉而開始推廣HTML5生態體系（包括CSS和JavaScript）。但是官方卻說Silverlight沒變化，對此我非常懷疑，也通告報道此事，而后我的團隊決定停止Silverlight開發，轉向集中精力投入“經典”的WPF開發，順帶還能獲得一些好處（比如，Silverlight不是“即插即用”的，而是首先需要管理員權限安裝Silverlight運行環境。

值得慶幸的是，大部分的XAML和C#代碼（大約85%）是和WPF共享的，因此沒有損失太多，不需要做太多的確認我們就停下來了。
最終這是一個正確的決定，因為到2013年微軟官方宣布Silverlight終止，很多的IT相關人員非常吃驚，因為他們沒有收到任何前兆。
我想此類事情不會粗暴的再WPF身上發生，但是我認為，在當今的IT環境和上下文中，你肯定很失望，從此多疑，甚至完全不信任。