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

最新推荐文章于 2024-07-24 06:58:51 发布

weixin_34357887

最新推荐文章于 2024-07-24 06:58:51 发布

阅读量292

点赞数

文章标签： c# 操作系统 javascript ViewUI

在前面的上、中篇中，我们已经能够看到园子里朋友的点评“后山见！ 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。

[完。]

完整系列文章文件夹：

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