WPF 对决 Silverlight：为项目选择最佳技术

在何时使用 WPF，何时使用 Silverlight 的问题上，很多人备感困惑。为项目选择正确的技术取决于应用程序的需求，以及 WPF 和 Silverlight 能力的不同之处。

Silverlight 最初称为 WPF/E（E 来自于 Everywhere 的首字母），是面向运行在浏览器中的 Web 应用程序的一个 WPF 子集。如今，Silverlight 以其快速的开发周期广为所知，且持续得到众人的关注，很多人认为它会成为微软未来的重要开发平台。 Mike Strobel 认为微软对 WPF/Silverlight 的考虑有一些混乱。

我认为最重要的事情，是提升 WPF 本身的影响。微软应该推动 WPF 成为富桌面应用程序的“核心”平台。然而恰恰相反，微软此时正推进 Silverlight 成为这样的平台。这会误导那些对两个平台都陌生，且不明白 Silverlight 不兼容标准.NET 函数库的人。

某些人则认为 WPF 就快消亡了，不过 Brian Noyes，一个微软区域技术领袖（Microsoft Regional Director）及微软最有价值专家（MVP），相信至少在未来几年不会出现这种情况。为了证明对 WPF 的这种看法，Noyes 在如下几个方面强调了 WPF 和 Silverlight 之间的一些重要不同点：

特性 WPF Silverlight 文件访问 无限制 可访问用户文件夹：我的文档、我的照片、我的视频等 打印 具有很多选项，可访问打印对话框、打印队列等 需编程打印 UI 元素 文档编辑 支持流文档和固定文档，有 RichTextBox 编辑支持，并能和流文档进行集成 RichTextArea 具备 WPF 的 RichTextBox 的大部分功能 命令 支持在按钮、超链接和菜单项上触发命令，键盘快捷键的输入可绑定到命令上，可实现路由命令 支持在按钮、超链接和上下文菜单项上触发命令，无输入绑定，无路由命令 通信 支持 WCF 的完整功能，能够调用和托管任何类型的服务，支持完整的安全选项和其他 WS-* 协议，支持 REST 和很多种低级通信方式 有限的 WCF 客户端功能子集，不能在客户端上暴露服务，支持不安全 TCP 或 HTTP 协议，比 WCF 客户端弱的双向通信（只能使用 HTTP 或不安全 TCP），支持某些 socket 级的功能，在很多部署场景中必须考虑跨域访问问题。 剪贴板 任何可序列化的对象 只支持文本 拖拽 任何东西 只能是文件 外部设备 有驱动、COM、Win32 或通信协议支持的任何设备 网络摄像头、麦克风和有 COM API 或通信协议支持的设备 输入 键盘、鼠标、手写笔、触摸屏，基本没有任何限制 必须在信任提升的 OOB 中，全屏时才能获得完整的键盘支持在 WPF 和 Silverlight 中还有一些不同的基本功能，这也可帮助大家来决定使用哪种技术。下面的例子，是一些开发人员做出选择的解释。

Joe Gilkey 在回答选择 WPF 而非 Silverlight 的问题时，解释了它的公司为何在一个项目中选择了 WPF，而在另外项目中选择 Silverlight：

在规划我们的软件产品时，确实遇到了这样的问题。对于我们而言，决定因素是是否需要访问本地硬件，以及（或者）本地数据库。我们的主打产品，需要在本地 100% 地运行。我们需要在本地 SQL 数据库中缓存信息，并且要访问一些硬件设备（GPS 接收器、串口、WCF 点对点通道、同步服务等等）。那个产品就由 WPF 来编写。而其他两个开发之中的产品，不用在本地保存信息（除了使用独立存储区），所以我们转而使用 Silverlight。两个 Silverlight 产品都支持脱离浏览器安装方式。WPF 应用程序的另外一个决定因素是对触摸的支持更加友好。感谢 Surface 团队，帮助我们在 WPF 应用程序中使用针对 Windows Touch 功能的 Surface Toolkit。

另外一个开发人员，Jeff 解释了为什么他的公司一开始使用 WPF 开发的项目后来又转用 Silverlight ：

一年前，我们使用 WPF 开发了多媒体发送系统的自定义客户端。明年，我们将用 Silverlight 应用程序来替换这个 WPF 客户端。为什么？目前我们的大部分应用程序都是基于 Web/ 浏览器的，不过我们也需要一个静态客户端来处理硬件交互和一些相对复杂的问题。现在，Silverlight 具有的 OOB 模式意味着我们能够通过 COM 来连接本地硬件，这样问题就迎刃而解。为什么 Silverlight 在对战 WPF 中胜出呢——这是因为我们客户的运行环境的安装问题。不必自己处理操作系统的不兼容和功能差异，Silverlight 都能正常运行。并且，现在升级也轻而易举，只用升级服务器，客户端就能自动升级。当然，WPF 更加强大，不过很多东西我们用不上。

在解释了 WPF 和 Silverlight 的区别之后， Noyes 总结道：

根本的决定因素是，如果你的客户端应用程序主要是为了展现后端数据的前端界面的话——选择 Silverlight 4 已经完全足够。不过，如果你的客户端应用程序需要更紧密地和客户端机器集成，并且其他一些东西也要放在客户端的话，使用 SL4 的信任提升 OOB 模式也可能胜任，但是这样会给开发带来更多的挑战，也可能需要牺牲开发效率或功能来达成开发目标。你需要切切实实地做好前端需求分析，如果应用程序和客户端机器资源有大量的交互的，WPF 仍旧是最好的选择，能让你的开发工作事半功倍。

关于未来，一个微软的资深产品经理 Pete Brown，认为这两种技术， WPF 和 Silverlight 最终将合二为一：

我最近和微软的 Ian Ellison-Taylor 交谈过。Ian 是一个直接向 Scott Guthrie 报告的总经理。在很多工作中，他的团队要开发 Silverlight 和 WPF 两者中的东西（以及 RIA Services 和其他很多东西）。我提到，我想在未来获得一些小道消息，他说可以为我提供一些。所以，他和我谈到了 Silverlight 和 WPF 合二为一的事情，并在随后互发了一些关于这个话题的邮件。

未来，Silverlight 和 WPF 很可能会成为一个基于同一份代码的单一技术。毕竟，Silverlight 是源自于所谓的 WPF/E（E 表示 Everywhere），并以我们出乎意料的方式，弃用了这个丑陋的开发代号，而创造了一个美妙的产品名称（Silverlight）。

在给出相关建议的时候，Brown 的观点和 Noyes 的也类似：“向右看，Silverlight 是完成面向跨平台 RIA 的最好方式。向左看，WPF 是编写用于 Windows 7 的托管代码应用程序的最好方式。”

查看英文原文： WPF vs. Silverlight: Choosing the Best Technology for a Project