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今生未来（下）：安心