WPF老矣，尚能饭否——且说说WPF此生将来（中）：策略

本文接上文《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环境和上下文中，你确定很失望，今后多疑，甚至彻底不信任。

[未完待续]

 

鉴于在《WPF老矣，尚能饭否——且说说WPF此生将来（上）：担忧 》网友们评论的特别声明：

葡萄城最近1月发布的Spread Studio 8和ComponentOne 2014V3、ActiveReports 9依然对WPF、WinRT、SilverLight提供产品升级和技术支持。

 

完整系列文章：

• WPF老矣，尚能饭否——且说说WPF此生将来（上）：担忧

• WPF老矣，尚能饭否——且说说WPF此生将来（中）：策略

• WPF老矣，尚能饭否——且说说WPF此生将来（下）：安心