WPF老矣，尚能饭否——且说说WPF今生未来（下）：安心

在前面的上、中篇中，我们已经可以看到园子里朋友的点评“后山见！ WPF就比winform好！激情对决”。看到大家热情洋溢的点评，做技术的我也很受感动。老实说，如何在本文收笔--WPF系列文章，我很紧张；我希望大家阅读完本系列文章后：各取所取、尽兴而归。坦白的说，葡萄城作为一家专注.NET技术的公司（仅海外分公司之一的西安葡萄城已经成立26年），我们几乎走遍了微软的技术路线，无论从技术前瞻性、或是技术深度均有涉猎。我们做控件的，也是非常想知道WPF未来走势如何。

但抱歉的是，我无法预测未来WPF会怎么样：

WPF to die? or not to die！

我只能在本篇收尾披露葡萄城Spread Studio系列产品技术研发路线，与大家共勉：

you can't connect the dots looking forward;

you can only connect them looking backwards.

---------摘录一段乔布斯在哈佛大学的演讲词。

有理由安心

在前面的2篇中你肯定认为我在“黑”微软，而事实上这确实是在“黑”微软。但是事物都有两面性，“黑”完了，也得夸一下，再就是给大家分享一些微软积极和改进的WPF地方，咱继续……

仍是活跃的团队

根据Greg Levenhagen的文章信息（WPF已死？——不，没死）得出目前仍然有一个开发团队专注在WPF的开发工作上；但Greg没有确切的说明具体数字，因此不能明确的衡量这个团队的作用。
但是很明显的一点是：微软没有放弃这一项亿万人使用的技术，仍然有专职开发团队而不是合并到其他团队里。这已经是一个好消息了。
另外从Greg的信息里得出，这个团队不仅是在维护已有的版本，同时还在积极准备着手下一个版本的开发工作（会是WPF5吗？）。当然在没有给这个版本的变更说明的情况下，我们很难保持乐观，因为很可能它只是一个漏洞修复和性能调整，没有主要功能。

仍在开发中（2014-11月更新）

在2014年11月WPF团队发布了一篇新的文章——WPF路线图（The Roadmap for WPF），表明WPF仍在进行开发。该团队的工作重点是修复主要的问题，比如性能，这个从WPF一开始就带着并已持续修复增强的问题点，另外还有和Visual Studio开发套件深度集成等等点。
或许另一个更重要的是完全支持触摸设备和高分辨率设备，表明微软听到了社区的声音并采取了相关的措施。

新版本的工具

我注意到另一个在官方工具这边的正面的信号，Prism，这个由一些列工具和开发XAML程序的最佳实践组成的产品，随着WinRT的版本升级也已更新到版本5.0，同时也是为WPF提供的一个新版本。
正如第一部分前文所说，官方的WPF Toolkit已经停了，而另一个项目接过了接力棒，它就是Externded WPF Toolkit，一个由著名的第三方扩展提供商Xceed开发的项目。因此，从一个WPF开发专家（同理可以是其他的Windows技术）角度来看，这是一个由一系列控件组成的内容丰富的合集，更重要的是它还在开发着，最新的更新是2014年7月，也就是写本文的三个月前的事。
最后还有两个上层MVVM框架库，MVVM Light Toolkit和Caliburn.Micro，也是活着的，最新版大约三个月左右。
因此WPF的工具生态系统还是活着的，并持续演进进化着，对于企业来说这太令人欣慰了，因为不会留下一堆不可维护的项目而发愁了。

管理层的改变

在2012年末，当时的Window部门的总裁Steven Sinofsky离开微软。为什么说这是给WPF的一个正面信号呢？因为Steven Sinofsky是一个彻底的.NET反对派，并且和其他团队搞不好关系（或许这是他离职的主要原因）。这也可以片面的反映出为，并非由于一些技术原因，导致.NET技术没有在下一代Window中作为基础存在，虽然这个微软创立的技术业已软件开发的重要部分之一。从外部来看，很难评估出在Window 8+中Steven Sinofsky的真实感受和在设计决定中所起的影响。

操作系统市场保守性

另一个WPF的有利消息是，事实上无论公司和个人都不会立即迁移到最新的操作系统，其中有一堆的理由：比如太花钱，比如太费时间，比如风险太大。
实际上迁移到最新的系统确实是一件令人望而却步的过程，因为需要保持应用程序的兼容性：这包括那些外部供应的，譬如微软办公套件，还有一些内部团队开发的部分。从我个人经验来看，这些软件的构建，会轻轻松松耗掉两年多时间。
当前（2014年中）在PC市场份额中的WinRT所占比例显得特别落魄：

Windows 8 + 8.1 : ~15%
Windows 7 : ~55%
Windows Vista : ~5%
Windows XP : ~25%

因此PC市场超过80%的设备不能使用WinRT，除了WPF之外别无他选。另外在某些领域对于Window 8+来说更糟：在我所知的法国公司里，财务这一块对其采用率是零，几乎所有的都没有完成向Windows 7的迁移，甚至其中我所知道的不少仍使用Windows XP，因为安装应用对他们来说不是问题。

考虑这个更新换代过程将大约有五年时间，在此期间，WPF将是大量应用的唯一选择。

应用程序生命周期保守性

你应该知道要迁移一个应用是很费事的：首先你得参与一些列会议并学习对业务的影响，还得在合适的时机努力的把各种“可控的风险”摆到台面上，然后通过新的应用一一搞定，同时还得保证不能有反复。通常在完成完整的切换过程之前还得保证新的和老的应用能同时工作；更甚你还得呼叫数据库团队来迁移数据，网络团队来更新防火墙规则……
这就是为什么企业应用程序直到有合理的业务原因才会做迁移的原因，而新技术不是问题，因此，很多现有的WPF程序会停在这里，这意味着WPF技能在可以预见的将来仍然有需求，你只需要看看大量现有的和新开始的WinForm应用程序就可以明白，虽然WPF从2006年就开始替代它。

从技术角度来看，WPF和WinRT是很相似的，但是不完全兼容：仍然有很多的功能在WinRT 8.1中没有或者不同，譬如在WPF中可以使用clr-namespace去映射一个命名空间到XAML中，到WinRT中，这就是XAML兼容问题，让人感觉如履薄冰。

WPF很成熟

很明显WPF的开发支出显著下降，这看起来值得担心。

但是据我的经验看来，每一个开发人员都有类似的经历：第一版开发工作量巨大，后续的发布就会从社区反馈获得好处，最后只需要很小的维护工作。
这确实是WPF自第一次发布（WPF 3.0（我个人看到的更早的Beta）和WPF 3.5）以来为windows应用程序开发指明的路线；然后WPF 4.0又从工具包（WPF Toolkit）里移过来一些控件，像DataGrid，同时做性能提升，到最后WPF 4.5引入了Ribbon同时依然做性能提升。
成熟的技术只需要更少的开发支出，经过八年时间，WPF已经很成熟，其新功能和bug修复都已经大大减少。到如今WPF可以说已经进入维护状态，在它的生命周期里，已经不需要“奋发图强”式的做增强开发了。

业务线生态

如果说在某个领域WPF做得很好并一直闪耀的，那一定是业务线（Line Of Business）应用。
首先大部分专家都是基于.NET做开发，因为它是一个成熟的平台，同时很多公司在Windows平台上开发他们的业务线应用，这些肯定不会被抛弃，而是尽可能的被重用。
还有很多以.NET为中心的工具在WinRT下不可用，例如，对象关系映射（ORMs）中得NHibernate或者Entity Framework，而这些恰恰业务线应用访问关系数据必不可少的组件。
其次，一些大型的业务线应用像交易平台，根本不能从WinRT平台获得好处，因为根本就不需要，甚至限于安全性和移动性，压根就不想要。因此像这一类大型应用一度反对微软WinRT应用的设计规范和指导：他们只想在屏幕上显示最小集合的数据！

学习曲线

如果你是一个经验丰富的WPF开发人员，可以说超过80%不需要再学习就已经是WinRT开发人员了，如果你是业务专家，那么80%的经验可以直接应用到WinRT程序中。

原因就是用来开发WPF应用的大部分基础工具和WinRT是一样的：

一样的编程语言：C#，VB.Net……
一样的标记语言：XAML
一样的方式关联视图和数据：数据绑定（Data binding），数据模版（DataTemplates）……
一样的设计模式和实现：MVVM，INotifyPropertyChanged, INotifyCollectionChanged, ICommand……

因此你在其他基于XAML平台比如WPF和Silverlight的投资可以延续到WinRT上，并缩减学习曲线的陡峭度（还记得当初还是一个学习WPF的新手吗？）

WPF内容丰富

WinRT不是一个WPF的克隆，其中很多的功能都没有实现，因此如果你只是开发桌面应用程序，从技术能力来说WPF是一个更好的选择。但是我把它放在最后一条，因为就我个人而言，我觉得这并不非常重要，WinRT还一直在向前演进，它们之间的差距将会越来越小，但是我仍然猜想一些开发人员不想在WinRT上开发，而是想要WPF。
再次说明WinRT的附加值不是在其本质上得技术增强，而是在开发模型上提供了移动平台开发能力和部署到微软商店的能力。

未来战略

无论你是企业开发还是个人开发，你都应该考虑减缓对WPF的技术投资，转而培养在WinRT方面的专长。

业务

在业务方面，因为有一些老版本的Windows，包括Windows 7，所以肯定不能停止你的WPF开发工作。对于那些已经存在的应用，也不用担心，没有必要要迁移到WinRT，除非你想要获得新的能力或者和微软商店兼容。可以预见不久的将来微软会对WPF做支持的，对于微软来说，向后兼容是一件很重要的事情。举例来说，虽然已经很难在最新的Windows里建立VB6的环境，但是你仍然可以做到，因此你的应用包括安装都会一直能平滑的工作。
根据你的可用的工时，你应该把时间专注到技术潜力上，同时让一些开发人员开始认真的考虑一下WinRT：如何从中获得好处，尤其是在开拓用户方面；新的应用将如何开发；如何重利用已有的工具和代码；什么是要关注的潜在问题……
做一个应用，要想从为手机和平板设计的WinRT中得到好处，得需要先制定好迁移路线，很明显的原因就是WinRT中缺失了很多WPF种的许多功能。从概念设计开始就应该验证新技术在你的情景中适用度。

开发

作为一个开发，我们不希望我们的技术技能是没人要的，而是建立足够强大的技能组合体以满足更多的业务和项目，以此降低被技术抛在后面的风险。因此，作为一个经验丰富的WPF开发人员，就我个人经验，你应该在选择继续强化你的WPF技能或者转向获得WinRT开发技能之间选择后者。
或者你可以继续在WPF领域等待直到市面上稀缺WPF开发，就像如今的COBAL和VB6这类老技术一样，但是我估计还得等十年。因为随着IT业的发展，任何技术在市场上都会有很多的开发人员，尤其是像WPF这样的主流技术，所以我是不指望这个。
但是也不必面对第n个冒出的新技术而从此意志消沉，这就是我们这个行业的商业模型：它需要无时无刻的创造新事物（还记得SOA为各大IT公司，他们的雇员、股东和承包商赚了大笔大笔的银子吗）来卖给客户，就像苹果公司（Apple）的iPhone系列，从iPhone 1，2，3……到如今已经6了，估计不久将来就42啦，但这就是它的工作模式。庆幸的是作为开发商的我们，在众多的壁垒上有我们的优势，我们轻松以此为生，客观的说，这些新技术丰富了企业和个人的生活。

结论

综上所述，我认为这些事实是很清楚的：WPF过去辉煌过，如今还在用，在不久的将来会和WinRT会直接竞争，但是当WinRT获得更多投入和足够的市场份额之后，WPF就会像如今的VB6和WinForm一样被弃用。
重要的是我们不可否认，有些事情肯定会发生，不可避免的在脑子里产生悲观情绪。不要指望WPF还会复兴，在IT界肯定不会发生（当然了，COM可以说是借着WinRT之体复出），客观上讲，WPF没有在趋势和新事物上做任何量身定制的亮点。
当然，前途不是一片灰暗，WPF不是已经消亡和过时，或者正在死亡和弃用，它只是刚刚达到顶峰，当企业基础架构迁移到Windows 8+之后，未来的开发就会选择WinRT，那是WPF就会慢慢淡出。
请保持务实和透明：在WPF能给你的客户带来价值的时候使用它，但是得透露出相关因素，并帮助他们为将来做好准备。我已经在我的WPF培训的教材中交叉串入一些WinRT的内容，包含了一些简要总结来阐述这些事情，并根据它们的重要性将它们一一突出。
但是就我个人而言，我觉得也不应该在WinRT做过多的投入，为什么呢？因为随着对WinRT摄入越来越多，我感觉好处正在一点一点减少：

如果你是一个业务线应用，你的唯一目标是Windows桌面，同时还得兼容Windows 8之前的系统，至少Windows 7，因从WinRT显然不是一个选项，你还得用WPF；
如果你面向平板和手机，请不要忘记，市场上得90%以上的份额是iOS和Android，所以WinRT压根就不是问题，此时你该选择使用网页技术（Javascript/HTML/CSS）或者像Xamarin（C#)或者QT（C++)这样的本地跨平台框架，就是说，大部分场景WinRT毫无用武之地。此外，应该知道微软正投入巨资在研究后续技术，此时提问是否WinRT已死还为时尚早，但是如果试图把WinRT作为主流的开发平台，我肯定会大吃一惊。

在我看来，WinRT是一个仅适用微软内部使用的良好平台，因为它可以很好的在不同的Windows系统层面上做代码共享，模仿苹果（Apple）的工作模式；但是对于最终开发人员来说，WinRT是一个非常有限的方式：在PC、平板和手机间共享代码但却只适用于Windows系列设备。或许很多业务其实只需要其中一个，但是我仍怀疑这一点，因为如今的应用通常是由员工个人提供设备（BYOD），它可以是任意设备，很大可能是iOS或者Android。

[完。]

完整系列文章目录：

---------------------------------------------------------------------------------------------------------------------------------