Silverlight，Wpf Web应用程序（xbap）或单击一次？ 优点和缺点
我们正在开始一个新的项目，我正在试图决定我们应该采取哪种Wpf-esque开发/部署策略。 在我们的例子中，我们正在看一个相当复杂的商业应用程序，将被100人（而不是1000人）使用，所以我倾向于一次点击一次的应用程序。 我的老板喜欢Silverlight应用程序的想法，因为这意味着更容易部署。 那么我们应该跳哪一条路？
答案当然是“要看情况”。 那么每个人的利弊是什么？
我会开始球滚动（ 编辑添加在一些答案从artur carvalho ）：
Silverlight的
- 优点
跨浏览器
不需要完整的框架。
更好地控制用户。 如果你的用户login，你不必担心激活密钥或类似的东西。
它适用于Windows和Mac。
您可以轻松更新所有的用户应用程序。
- 缺点
不能与客户端的文件系统等进行交互
与完整的Wpf相比，function更less（任何人都有一个很好的文档差异资源？）
单个窗口
单一版本
Wpf Web应用程序（xbap）
- 优点
完整的Wpf。
- 缺点
单一浏览器
需要完整的框架
不能与客户端的文件系统等进行交互
单个窗口
单一版本
Wpf单击一次
- 优点
完整的Wpf
可以离线工作
多个窗口
多个版本（con？）
更好地访问计算机的低级别部分
没有停机维护
- 缺点
单一浏览器
需要完整的框架
稍微 （？）难以安装。
首先，我会评估一个Web客户端（理想情况下，MVC + jQuery）不能完成这项工作…
假设完整的客户端是有保证的：
如果这是一个需要客户的商业应用程序，我会倾向于使用完整的框架和ClickOnce; 这里的重要区别（重新部署）是客户端必须安装框架 – 但过去，ClickOnce部署是非常痛苦的。 实际上，构buildClickOnce清单比Silverlight等要容易得多，因为IDE将为您完成所有工作。 您只需将文件托pipe在某处（可能是url;可能是networkingUNC）。
这给了你更多的客户端控制（和权力），以及更多的现有资源使用（例如，如果你需要的话，你可以在WPF表面使用一些传统的winform代码）。 “需要全面框架”也是最大的好处之一：“有充分的框架”。
你也应该考虑3.5“客户端configuration文件”设置; 不知道这是多么广泛的现实…但值得了解。
你没有说这是公司唯一的应用程序还是面向公众的应用程序。 那一个人会为你决定。
如果只有公司，我会用完整的WPF点击一下。 这会给你一切。 完整的框架不应该是一个问题。 这是一次安装在后台运行，所以这不是你的决定应该依赖的东西。 缺点：它只在Windows上运行，但是如果你的公司只有Windows，这应该不成问题。
然而，WPF应用程序可能是资源饥渴的，所以你需要知道你的所有客户端机器是否能够顺利运行WPF应用程序。
如果它是一个互联网应用程序，去Silverlight：它在不同的操作系统下运行。
PROs与ASP.NET Web窗体
- 没有ViewState或“惊讶废话”o这也适用于Silverlight。 Silverlight为最终用户带来了“桌面”体验，并且没有Silverlight中使用的ViewState。
- 更快的服务器端和客户端o根据您的看法，Silverlight在客户端/服务器端速度更快。 Silverlight是在Silverlight的.NET子系统中编译的。 您可以访问multithreading，LINQ，复杂的数据结构等。与ASP.NET或AJAX / JavaScript应用程序的性能相比，性能要好得多，因为客户端执行和一些通常在服务器BLL中处理的项目可以被带到客户端
- 多个相关视图的简化模型Silverlight支持完整的数据和UI分离。 进一步通过创build独立的观点来说，Silverlight的另一个消费者是非常强大的。 你可以在Silverlight中应用相同的MVC / MVP模式，并达到这个抽象级别。 Jason提到了能够为iPhone创build独立视图的示例，只有View组件必须更改。 这适用于Silverlight以及不同的事情。 例如，我有我想要移植到SharePoint的大型Silverlight应用程序。 我可以为SharePoint创build一个“更小的视图”，使其更适合用户界面。 此外，Silverlight Mobile现在正在进行私人testing。 我会假设同样非常强大的抽象级别也适用于为您的Silverlight应用程序创build“移动视图”。
- unit testingo Silverlight也包含unit testing框架。 它可以在这里下载： http : //code.msdn.microsoft.com/silverlightut/
- 如果您没有运行IIS 7，则面临挑战o如果您没有在IIS 6或IIS 7或Apache上运行，Silverlight不在乎。 这是Silverlight比ASP.NET MVC更有优势的一个特性。
- 客户端cachingo在ASP.NET Web窗体或MVC中，您正在服务器上进行caching。 Silverlight允许你通过隔离存储（在需要的时候可以增加到数百兆）在客户端caching。 这使应用程序可以执行超快速，而不会让托pipe服务器陷入困境。
CONs与ASP.NET Web窗体
- 很难转换现有的代码o Silverlight是一个完全不同于ASP.NET WebForms或MVC的编程平台。 不仅会有很多代码不能转换，还需要考虑客户端层，而且在大多数情况下，如果要replace现有ASP.NET网站中的大型模块，则需要完整的重新架构。
- 不是最好的search引擎优化开箱即用谷歌几个月前开始蜘蛛SWF文件，并将其添加到search引擎。 我认为Silverlight在这里可能还有一段路要走。 您可以为Silverlight做什么search引擎优化是一个基本的技巧来描述元数据标签真的很好插件。
- 数据访问o Silverlight中的数据访问仅限于Web服务/ WCF / ADO.NET数据服务。 您不能通过ADO.NET或存储过程直接调用数据库。
- 安全o Silverlight运行在客户端上。 在互联网上，你的很多东西在野外漫游。 此外，某些数据访问技术不支持完整的WS *标准安全性。 因此，除了基于证书的运输安全之外，您要么编写很多自己的pipe道代码，要么等待下一次修订。 XAML代码几乎不安全; 很多应用程序在他们的用户界面中都没有知识产权 在Silverlight中，使用Silverlight Spy可以很容易地进行逆向工程。 Silverlight本质上比ASP.NET MVC应用程序稍微安全一些。 很明显，你可能想在encryption/混淆Silverlight程序集之前先让它们closures。
1. Silverlight可以从托pipe页面访问DOM
2.托pipe页面可以访问Silverlight部分。
这对于Silverlight来说是一个很大的提升
但是所有其他的限制都要求使用Clickonce的 WPF / Windows-Forms
文件访问，鼠标右键单击，便于数据库访问
专业人士
- Silverlight插件意味着开发人员可以针对基于浏览器的应用程序定位一个一致的运行时，而不是处理不同版本中多个浏览器的复杂性。 您还可以通过纯HTML和JavaScript获得video和多媒体效果，但Adobe Systems的Flash具有相同的优势。
- 在不部署.NET运行库的情况下执行.NET代码。 Silverlight插件确实包含了一个精简的.NET运行库，但是用户不需要处理大量的下载和Windows安装程序的复杂性，而是可以在浏览器中处理大约4MB的小型下载。 以我迄今为止的经验，安装顺利而简单。
- 性能是有希望的。 在这个质数计算器中，Silverlight出现得很好，毫无疑问，要将JIT编译为本机代码，尽pipe它可能无法比较好地渲染graphics。
- 对月光的支持意味着将有一个官方的Silverlight开源实现，减轻专有的方面。
- Silverlight直接解释XAML，而Adobe的XML GUI语言MXML在编译时转换为SWF。 实际上，XAML页面作为资源包含在用于部署Silverlight应用程序的已编译的.XAP二进制文件中。 .XAP文件只是一个具有不同扩展名的ZIP。 这也意味着search引擎可以在Silverlight应用程序中索引文本，就像使用Flash一样。
- 第三方组件供应商已经开始使用Silverlight附加组件。 例如，Infragistics，ComponentOne和DevExpress。
- 把你的.NET代码跨平台。 Mac随处可见，将Visual Basic或C＃代码迁移到跨平台，基于浏览器的Silverlight客户端的能力将越来越有用。 显然，这只适用于现有的.NET开发人员 – 我猜这是Silverlight的主要市场，但它是一个很大的市场。 下一点同样适用：
- 使用Visual Studio。 微软的IDE是一个成熟且广受欢迎的开发环境，因为它也是ASP.NET的工具，所以你可以将它用于服务器端代码以及Silverlight客户端。 对于那些没有使用Visual Studio的人来说，Silverlight SDK也支持命令行编译。
- select你的语言。 自从.NET开始以来，支持多种语言已经成为.NET的一部分，在Silverlight 2.0中使用.NET运行库意味着您可以在C＃，Visual Basic中编写您的客户端逻辑，或者感谢dynamic语言运行时（DLR）Iron Ruby或铁蟒。
- 独立存储为Silverlight应用程序提供了本地文件访问权限，但只能在特定于应用程序的受保护位置中提供，从而为获得此益处提供了相对安全的方法
缺点
- 如果苹果甚至不允许在iPhone上使用Flash，Silverlight有什么机会？
- Silverlight迟到了。 Flash是成熟的，值得信赖和无处不在的。 Silverlight 2只能在秋季推出（我们希望）。 它是我们关心的版本 – 包括.NET运行时版本的版本 – 并且仍然缺乏对移动设备（即使Windows Mobile）的支持，尽pipe这在稍后的某个未指定的date中会得到承诺。
- devise工具是Expression Blend和Expression Design – 但是谁使用它们？ devise世界使用Adobe PhotoShop。
- 尽pipeExpression Blend和Visual Studio之间的解决scheme兼容性听起来不错，但实际上却是一个麻烦，必须使用两个单独的工具，特别是在当前testing版中存在不兼容的情况下。
- 不支持stream行的H.264video编解码器。 对于Silverlight而言，高清video必须位于VC-1中，这种情况并不常见。
- 推广专有技术而不是开放标准是另一个努力。
- 是的，Linux将通过月光支持，但什么时候？ Linux实现似乎可能总是落后于Windows和Mac版本。
- 如果您不使用PUT或DELETE，Silverlight支持SOAP Web服务或REST，但没有像Adobe的ActionScript Message Format（AMF）这样的优化二进制协议，这可能意味着在某些情况下性能较低。
- Silverlight是一个纯浏览器的解决scheme，而Flash则可以使用Adobe Integrated Runtime（AIR）为桌面部署。 话虽如此，是的，我已经看到了这一点。
- 你必须在Windows上开发。 对于Expressiondevise工具而言，这尤其是个问题，因为devise者拥有不成比例的大量Mac。
您可以添加在线与离线辩论的平常东西的利弊。 一些项目：
优点
WPF（离线）：
- 更好地访问计算机的低级部分。
- CPU使用率是本地的，所以你很less有CPU负载的问题。
- 不依赖networking。
- 没有停机维护。
Silverlight的（在线）：
- 更好地控制用户。 如果你的用户login，你不必担心激活密钥或类似的东西。
- 它适用于Windows和Mac。
- 您可以轻松更新所有的用户应用程序。
我简化了一下，列表中有灰色的地方。 我只用XBAP修饰，所以我会抛弃一个。 在向职业球员展示之后，Cons不难看出。
HTH
我会考虑带有同步框架支持的WPF ClickOnce（ http://www.msdn.com/sync ）。 这将允许您在用户没有连接到公司networking（这将消除任何基于浏览器的部署scheme，如Silverlight和XBAP）时支持有限的function。
如果你不需要所有的WPF，我会尝试在Silvelight中先做。然后你可以更容易的切换到WPF，如果你以后需要的话。
在这里，我认为它适用于“less即是多”的原则：确实，使用WPF，您有更多的select，并可以访问用户计算机，但随着时间的推移，这最终可能成为一个问题，而不是帮助。 例如，考虑在使用大量“用户计算机”资源的应用程序中，您可能需要从Windows XP更改为Vista的更改次数。
Mark，XBAP的单一浏览器是什么意思？ 例如，XBAP可以和Firefox一起工作。 它的确需要.NET框架，我们不可能在任何地方很快（如果有的话）在Mono中使用WPF，所以你被困在Windows中，这是正确的。
这些日子不会在Firefox上点击一次，通过这个插件： https ： //addons.mozilla.org/en-US/firefox/addon/1608
