Windows和业务线应用程序：没有更好的选择

在Windows平台上创建一个新的业务线应用程序从来就不是什么难题。但是，和以前那样，对于某类确定的问题只有一个明确的解决方案——这样的日子已经一去不复返了。在过去的二十年里，面对大多数问题，我们都有更好的选择。比如，Visual Basic的快速交付或MFC原生的性能和功能。还有WinForms的速度以及WPF的外观。当WinForms时代结束的时候，我们将Silverlight作为第二选择。虽然和WPF相比，它没那么强大，但它更容易部署。

而如今，我们虽然有了比以往更大的选择空间，但是可选择的方案却差强人意。比如，虽然WinRT提供了三种开发模型，但没有一个是适合业务应用程序的。与此同时，WPF加入了Silverlight的阵营，而等待WinForms的只有灭亡。

WinRT：尚未完成准备

是否选择一款依赖于Windows 8的平台——对于这个问题我不打算在这里讨论，因为最终企业都将会采用Windows 8。我也不打算讨论目前WinRT 8所存在的问题，诸如被限制在单一的窗口或没有设备集成等等。因为在Build 2013大会上，微软已经宣布了这些问题将在WinRT 8.1中修复。

我要谈的问题比前面的简单很多，而且要更加初级。坦白地说，部署场景与现实脱节了。WinRT明显存在有人格分裂（Dissociative Identity Disorder），但在这种情况下，微软的消费者和企业双方却处于僵持状态。消费者一方要求WinRT在Windows商店保持锁定状态，这样在每个软件销售之后，他们都可以获得一定比率的提成，这类似于苹果和谷歌成功的战略。而与此同时，微软的企业一方则背负着WinRT的未来，但他们甚至没有认识到对方已产生的问题。

WinRT应用在企业中的部署

用户们如果想要将WinRT部署在企业中，必须要满足三个要求。

第一个要求是，所有的机器都要加入某个域。对于大企业来说，这个要求还算合理的，但对很多小公司甚至一些中等规模的企业来说，根本没有足够的资源来维持一组Active Directory服务器。大多数企业都不是搞技术的，他们只需要少量自定义应用，而非整个IT基础设施——而我们总是忘记这一点。

另一个问题是，一些公司虽然部署了Active Directory，但没有必要让所有机器都加入Active Directory。导致这类问题的原因有很多种，可能不全是合理的，但是依然需要满足这些公司的需求。

据说，对于未加入域的计算机将会有一个替代方案。2012年4月，Antoine Leblond曾作出承诺，后续将在博客中发表文章，描述如何通过获得必要的产品密钥来做到这一点。但是，迄今为止，这篇文章还未撰写。

第二个要求是“允许安装所有受信任的应用”的组策略，这一点对于已加入域的计算机来说十分合理。对于未加入域的计算机，需要用户手动编辑注册表，通常我不赞成这种做法。不过，可以通过添加脚本来实现。

第三个，也是最后一个要求，不太受人欢迎：所有机器必须要信任某个证书，而所有的应用程序都需使用该证书签名。这意味着需要创建一个自签名的证书，并手动安装到每一台机器上，或者花费几百美元从一个可信的证书颁发机构获取代码签名证书。

一旦满足上述所有要求，用户就可以学习如何调用PowerShell命令来安装应用程序，但无法使用ClickOnce安装。用户甚至不能双击批处理文件安装，因为PowerShell默认禁止从Windows资源管理器中运行脚本。

WinRT应用的更新

Antoine写道，

对最终用户而言，没有标准方式去检测并获取这些应用的更新。

在使用了近十年的ClickOnce自动更新之后，我们又回到手动更新工作站的时代。现在，用户必须再次输入PowerShell命令。并且与以前不同的是，他们需要在路径中包含版本号。例如，

add-appxpackage \\fileserver\ContosoApp\v1.1\ExpenseApp.appx 

Silverlight：废弃的技术

Silverlight实质上是一种废弃的技术。不像Adobe Flash，目前连Internet Explorer 10都不能完全支持Silverlight。并且，在基于ARM的计算机上，它根本无法运行。

Silverlight完善吗？不。

一些现任的和前任的微软员工争辩道：Silverlight是“完善的”，它不需要任何改进。我觉得这种说法非常可笑。

虽然Silverlight工具包包含了很多关键的用户控件，但是自2011年12月以来，我没有看到任何相关的更新，此外，许多控件没有达到产品发布的要求。 更糟的是，Silverlight中仍然没有一个能用的单元测试框架。虽然在工具包中有一个预览版本，但它存在一些设计缺陷，使用它将导致测试花费O(n^2)的时间。我们自己进行实验后发现，尽管每个单元测试在单独测试时只需要几毫秒，但是几千个一起测试就会导致测试过程长达一个多小时。另外一个急需解决的问题就是修改UI——已经通过的测试还显示出来那就太占地方了。

WPF：仍处于维护模式

虽然我不想这样说，但是现在来看，WPF的未来似乎比以往任何时候都黯淡。

性能问题尚未修复

WPF很慢，真的很慢。这一点在很大程度上可以归咎于开发人员做的那些不计后果的事情，比如甚至会加载标签中上千个不可见的屏幕元素。或者给用户控件添加过多的效果，我曾见过的一个项目，每个文本框包含9个边框，并且每个边框都使用自有的渐变画笔。

虽然这么说，微软仍然可以在WPF渲染管线方面做很多调整。但很明显，应用于WinRT/XAML的内容已经主动地放弃了移植回WPF或Silverlight的选择。

被遗弃的路线图

自2010年4月之后，我就再没看到WPF工具包发布新版了。起初看起来，微软只是暂时搁置WPF，好让新宠Silverlight可以引起一些关注。但是自那以后，WPF Ribbon工具栏、AutoCompleteBox、 Accordion控件以及WPF未来路线图中所涉及到的内容，再也没有进行任何完善工作。

不许部署在低功耗设备上

Windows RT版应该部署在一类廉价、低功耗、电池容量高、寿命长的设备上，适用于临时用户和大规模的部署。虽然现在它们的价格在下降，但也并不便宜。因为WinRT不能运行“真正的.NET”，所以对于那些使用WPF作为业务线应用的公司来说，就不能选择WinRT了。

黯淡的未来

微软喜欢假装和苹果一样，对远景规划的重要公告保密。也就是说，他们可以继续研发WPF大量的增强功能，只是为了确保对用户来说是个惊喜。但是别忘了，苹果是一家硬件公司。如果读者们投资了一个iPod，当硬件损坏时，投资也就到期了。当硬件真的损坏时，大家会很高兴看到苹果公司推出新一代的产品。

但当用户使用WPF或Silverlight编写应用程序时，相当于要对需要使用多年的平台进行投资。那种不确定性一点也不会令人兴奋，相反，它是非常恐怖的。事实上，每隔几年我们就不得不经历一次这种“投资”，结果是这种“投资”变得越来越习以为常。

更糟糕的是，微软很少承认自己或者其他人正在放弃某种技术。比如，微软根本没有发布过有关WinForms的生命周期的公告。当Silverlight团队解散，并分配到其他项目中时，微软也没有发布任何新闻稿件。还有，没有人注意到LINQ to SQL的类型化数据集的支持已经取消了。直到它成为已拥有自有竞争框架的ADO.NET团队的一部分时，我们才意识到一直钟爱的LINQ to SQL已经被遗弃了。

目前具有生命力的平台

那么，WPF怎么办？目前，对于Windows用户来说，WPF仍然是最具生命力的业务线平台。凭借与OS的深度集成、少见的Silverlight问题以及支持ClickOnce的自动更新，在真正进行富客户端开发时，没有什么谁是WPF的对手。但同时也存在一个绝好的机会，机不可失，时不再来。因此对于新应用程序的开发来说，很难就这一点做出客观的评论。

ASP.NET：网站替代应用

我坚信，安装在本地的应用程序可以为用户提供最佳的体验。尽管Web建设得越来越好，但对于开发人员而言，它仍然存在很多方面的障碍。因为Web浏览器拦截了键盘快捷键，所以如使用F1帮助或F5刷新当前所选视图这种基本功能，在Web中也都不起作用。在更复杂的情况中，比如多窗口的支持，不管是对用户还是开发人员来说都是一个很糟糕的体验。又比如打印多页的报表，这在Visual Basic1中是支持的，除非你真想生成一个PDF，否则不建议你尝试。

我想说的是，这项技术是稳定的并且是不断提升的。它可以在所有Windows机器上运行，从低端的上网本、运行Windows XP的古董级PC，到最新的运行着Windows 8.1预览版的可翻转式平板电脑。在充分地努力下，开发者甚至可以让苹果、谷歌以及黑莓手机访问你的应用程序。

当微软在MVC方面做出了很多具体改进的同时，我们仍然可以看到WebForms在不断地发展。许多MVC的特性可以移植回WebForms 4.5，或者这些特性本来就适用于两者。并且，在同一个网站中，可以自由的混合使用MVC和WebForms，这样，开发者可以只选择其中一种方式，只不过要以渐进的方式进行。

开发者们不能再无视HTML5，因为它变得越来越流行了。对于中等规模的团队来说，像TypeScript这种技术的出现使得大规模、单页Web应用已经成为他们的一个不错的选择。或着可以将网站分解成一系列更小、功能更加具体的页面，这样会比整体应用更容易处理。

网站的交付时间依然是个关键，因为交付网站的时间通常是交付相同功能时间的3到4倍。但因为浏览器之间的兼容性越来越好，所以这种差异正在逐渐地缩小。

因此——虽然我不想这么说——但是对于那些正准备开发新业务线应用程序的公司来说，我建议他们应该认真考虑放弃原有的想法，并建立一个内部网站取而代之。

作者简介

Jonathan Allen自2006年以来持续为InfoQ撰写新闻报道，目前是.NET领域的责任编辑。如果您有兴趣为InfoQ撰写新闻或有价值的文章，请通过[email protected]与他联系。

查看英文原文：Windows and Line of Business Applications: No Good Options