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

概述　　在何时使用WPF，何时使用Silverlight的问题上，很多人备感困惑。为项目选择正确的技术取决于应用程序的需求，以及 WPF和Silverlight能力的不同之处。 　　Silverlight最初称为WPF/E（E来自于Everywhere的首字母），是面向运行在浏览器中的Web应用程序的一个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

总结

以上是内存溢出为你收集整理的WPF对决Silverlight：为项目选择最佳技术全部内容，希望文章能够帮你解决WPF对决Silverlight：为项目选择最佳技术所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。