写点什么

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

  • 2013-09-23
  • 本文字数:3829 字

    阅读完需:约 13 分钟

在 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 撰写新闻或有价值的文章,请通过 jonathan@infoq.com 与他联系。

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

2013-09-23 13:011969
用户头像

发布了 36 篇内容, 共 13.6 次阅读, 收获喜欢 2 次。

关注

评论

发布
暂无评论
发现更多内容

为语音社交平台加一个防护罩,即构上线实时语音安全方案

ZEGO即构

insert、update、delete注入总结

Cc.

网络安全

源码解析--skywalking agent插件加载流程

cloudcoder

Skywalking 源码剖析 插件设计

Flutter-从入门到项目 07: 微信项目-发现页面

iOSer

flutter ios 小程序flutter, 跨平台

真实!对比(阿里/京东等一线大厂)Java面试真题,自己把自己菜哭了

Java架构之路

Java 程序员 架构 面试 编程语言

币管家软件开发|币管家系统APP开发

系统开发

卓越级!浪潮云通过可信云云管理服务能力评估

CIO/CTO必读 | 数字转型时代,企业存储支出知多少

焱融科技

存储 焱融科技 CIO 存储成本 IT成本

网格量化交易机器人系统开发|网格量化交易机器人软件APP开发

系统开发

3分钟学会如何上手supervisor看门狗

happlyfox

Linux centos7 28天写作 2月春节不断更

分享我的2021京东4面面经,送给备战金三银四的你

Java架构之路

Java 程序员 架构 面试 编程语言

逆向思维:从小厂到面试大厂,这份学习笔记助我快速成长,实现高薪岗位

Java架构之路

Java 程序员 架构 面试 编程语言

瓦力量化交易机器人软件开发|瓦力量化交易机器人APP系统开发

系统开发

滴滴Kafka服务体系建设,实战干货都在这里!

滴滴云

大数据 Obsuite 滴滴Kafka

优化软件测试成本的7个步骤

程序员阿沐

软件测试 自动化测试 测试工程师 黑盒测试 白盒测试

python精度控制

里昂

Python 数据结构

容器 & 服务:Docker 应用的 Jenkins 构建(二)

程序员架构进阶

容器 服务化 七日更 28天写作 2月春节不断更

华为发布智能云网“五个一”新能力,助力运营商完成云与网的价值归一

脑极体

运维工程师小张的日记

XSKY星辰天合

Serverless 2.0,鸡蛋还是银弹?

Serverless Devs

腾讯云 阿里云 Serverless 运维 大前端

图解定时任务线程池

叫练

面试 定时任务 线程池 Timer 线程池工作原理

Docker 镜像加速教程

米开朗基杨

Docker 云原生

双指针高频面试题:三数之和的「升级篇」...

宫水三叶的刷题日记

面试 LeetCode 数据结构与算法

利用xml实现数据传输

天狼

「超全!」谷歌大神LeetCode刷题笔记PDF分享

C语言与CPP编程

c++ 程序员 算法 LeetCode 编程、

OpenYurt 如何 “0 侵入” 攻破云边融合难点

阿里巴巴云原生

云计算 Serverless 容器 云原生 边缘计算

应云而生,幽灵的威胁 - 云原生应用交付与运维的思考

阿里巴巴云原生

云计算 容器 微服务 云原生 k8s

翻译:《实用的Python编程》02_06_List_comprehension

codists

Python

大牛荐书 | 百度技术大牛都在读的7本书!

百度Geek说

技术 技术人 书籍推荐 技术书籍

架构设计篇之微服务实战笔记(六)

小诚信驿站

架构师 刘晓成 小诚信驿站 28天写作 架构师成长笔记

数字货币量化交易APP开发|数字货币量化交易系统软件开发

系统开发

Windows和业务线应用程序:没有更好的选择_.NET_Jonathan Allen_InfoQ精选文章