logo标签列表

Silverlight、WPF Web App（XBAP）或Click Once？优缺点

c#.netwpfsilverlight
37
我们正在启动一个新项目，我正在尝试决定我们应该采用哪种类似 Wpf 的开发/部署策略。在我们的情况下，我们正在考虑一个非常复杂的业务应用程序，将由数百人（而不是数千人）使用，因此我倾向于选择 ClickOnce 应用程序。我的老板喜欢 Silverlight 应用程序的想法，因为它意味着更容易部署。那么我们应该选择哪个方案呢？
当然，答案是“取决于具体情况”。那么每种方法的优缺点是什么呢？
我来开始介绍一下（编辑添加了一些来自artur carvalho的答案）：
银光（Silverlight）
优点：
跨浏览器
不需要完整框架。
更好地控制用户。如果您的用户登录，则不必担心激活密钥或类似的事情。
它可以在 Windows 和 Mac 上运行。
您可以轻松更新所有用户的应用程序。
缺点：
无法与客户端文件系统等交互
与完整的 Wpf 相比功能较少（有没有好的资源记录差异？）
单窗口
单版本
Wpf Web 应用程序（xbap）
优点：
完整的 Wpf。
缺点：
单个浏览器
需要完整框架
无法与客户端文件系统等交互
单窗口
单版本
Wpf ClickOnce 优点：
完整的 Wpf
可以离线工作
多窗口
多个版本（缺点？）
更好地访问计算机的低级部分
没有维护停机时间
缺点：
单个浏览器
需要完整框架
稍微难安装。
嗨，马克，我对你所说的wpf web应用程序很好奇。从未听说过，你能提供一个示例链接吗？谢谢。 - Artur Carvalho
1
我认为他在谈论XBAP。http://www.xbap.org/ - Ray
是的，我在谈论XBAP - 我会编辑我的问题以使其更清晰。 - Mark
10个回答
7
首先，我会评估是否可以通过Web客户端（理想情况下是MVC + jQuery）完成工作...
假设需要一个完整的客户端：
如果这是一个需要客户端的商业应用程序，我倾向于选择完整的框架和ClickOnce；主要区别在于（关于部署）客户端必须安装框架 - 但除此之外，ClickOnce部署非常轻松。实际上，构建ClickOnce清单比Silverlight等要容易得多，因为IDE几乎会为您完成所有操作；您只需要在某个地方托管文件（可以是Web URL；可以是网络UNC）。
这为您提供了更多的控制（和能力），以及更广泛的现有资源可供使用（例如，如果需要，您可以在WPF表面上使用一些传统的winform代码）。“需要完整框架”也是最大的优点之一：“具有完整框架”。
您还应该考虑3.5“客户端配置文件”设置；不确定这在现实中有多普遍...但值得了解。
3
你没有说这是公司专用应用还是公共面向应用。这一点将决定你的选择。
如果只是公司使用，我会选择完整的WPF单击一次。这将为您提供一切。 完整的框架不应该成为问题。它是一次性安装，在后台运行，因此您的决策不应取决于此。缺点是它仅在Windows上运行，但如果您的公司仅限于Windows，这应该不是问题。
然而，WPF应用可能需要大量资源，因此您需要知道所有客户机是否能够平稳地运行WPF应用。
如果是互联网应用程序，请选择Silverlight：它可以在不同的操作系统下运行。
1

优点

  1. Silverlight插件意味着开发人员可以针对单一、一致的运行时环境来设计基于浏览器的应用程序，而不必处理不同版本的多个浏览器所带来的复杂性。您还可以获得视频和多媒体效果，这些纯HTML和JavaScript很难或不可能实现，尽管Adobe Systems的Flash也具有相同的优点。
  2. 在不部署.NET运行时的情况下执行.NET代码。Silverlight插件确实包括一个瘦身版的.NET运行时，但用户只需在浏览器内处理大约4MB的小型下载，而无需处理庞大的下载和Windows安装程序的复杂性。根据我的经验，安装非常顺利简单。
  3. 性能非常有前途。Silverlight在这个质数计算器中表现出色，这无疑要归功于JIT编译为本地代码，尽管它在渲染图形方面可能表现得不太好。
  4. Moonlight的支持意味着将有一个官方的开源实现Silverlight，从而缓解了专有方面的问题。
  5. Silverlight直接解释XAML，而Adobe的XML GUI语言MXML在编译时会转换为SWF。事实上，XAML页面被包括为部署Silverlight应用程序所使用的编译.XAP二进制文件中的资源。.XAP文件只是一个具有不同扩展名的ZIP文件。这也意味着搜索引擎可以潜在地索引Silverlight应用程序中的文本，就像它们可以处理Flash一样。
  6. 第三方组件供应商已经非常熟练地使用Silverlight插件进行添加，例如Infragistics、ComponentOne和DevExpress。
  7. 跨平台运行.NET代码。随着Mac无处不在，将Visual Basic或C#代码迁移到跨平台的基于浏览器的Silverlight客户端的能力将变得越来越有用。显然，这仅适用于现有的.NET开发人员——我想这是Silverlight的主要市场，但这是一个庞大的市场。下一个要点也是如此：
  8. 使用Visual Studio。微软的IDE是一种成熟而受欢迎的开发环境，由于它也是ASP.NET的工具，您可以将其用于服务器端代码，以及Silverlight客户端。对于那些无法使用Visual Studio的人来说，Silverlight SDK还支持命令行编译。
  9. 选择您的编程语言。多种语言支持自.NET开始就是其中的一部分，而Silverlight 2.0中具有.NET运行时的功能意味着您可以使用C#、Visual Basic或Iron Ruby或Iron Python（由于动态语言运行时DLR而支持）来编写客户端逻辑。
  10. 隔离存储使Silverlight应用程序可以访问本地文件，但只能在特定于应用程序的受保护位置中进行，为获取此优点提供了相对安全的方法。

缺点

  1. 如果苹果甚至不允许在iPhone上使用Flash，那么Silverlight有什么机会呢？
  2. Silverlight来得太晚了。Flash已经成熟、信任度高且无处不在。Silverlight 2只在秋季（我们希望如此）退出beta版。这是我们关心的版本——包括.NET运行时——但它仍然缺乏对移动设备的支持，即使是Windows Mobile，尽管承诺在某个未指定的日期提供支持。
  3. 设计工具是Expression Blend和Expression Design，但谁在使用它们呢？设计界使用Adobe PhotoShop。
  4. 虽然在Expression Blend和Visual Studio之间具有解决方案兼容性听起来很好，但实际上使用两个单独的工具是一件麻烦事，特别是当存在问题不兼容性时，就像在当前beta版中一样。
  5. 不支持流行的H.264视频编解码器。相反，Silverlight的高清视频必须使用VC-1，这种编解码器不太常见。
  6. 这是另一个推广专有技术而不是开放标准的努力。
  7. 是的，Linux将通过Moonlight得到支持，但是何时呢？似乎Linux实现将始终落后于Windows和Mac版本。
  8. Silverlight支持SOAP Web服务，或REST，只要您不使用PUT或DELETE，但没有像Adobe的ActionScript消息格式（AMF）那样优化的二进制协议，这可能意味着在某些情况下性能较慢。
  9. Silverlight是一种仅限浏览器的解决方案，而Flash可以使用Adobe集成运行时（AIR）部署到桌面。话虽如此，我确实见过这种情况。
  10. 您必须在Windows上进行开发。对于Expression设计工具来说，这是一个特别的问题，因为设计师拥有相对较高数量的Mac。
1

PROs与ASP.NET Web Forms的比较

  1. 没有ViewState或“意外的垃圾” 这也适用于Silverlight。Silverlight为最终用户带来了“桌面”体验，并且在Silverlight中不使用ViewState。
  2. 更快的服务器端和客户端 就如何看待它而言，Silverlight在客户端/服务器端上都更快。Silverlight编译在Silverlight的.NET子系统中。您可以访问多线程、LINQ、复杂数据结构等。与ASP.NET或AJAX/JavaScript应用程序相比，由于客户端执行以及通常在服务器BLL中处理的某些项目可以下移到客户端，因此性能要好得多。
  3. 简化的多个相关视图模型 Silverlight支持完全分离数据和UI。进一步地，只需为另一个Silverlight消费者创建单独的视图就非常强大。您可以在Silverlight内部应用相同的MVC/MVP模式并实现这种抽象级别。Jason提到了一个例子，即能够为iPhone创建单独的视图，只有View组件需要更改。对于不同的事物，这也适用于Silverlight。例如，我有一个大型的Silverlight应用程序，我想将其移植到SharePoint。我可以为SharePoint创建一个“较小的视图”，使其更好地适应UI。此外，Silverlight Mobile正在进行私人测试。我认为同样强大的抽象级别也适用于为您的Silverlight应用程序创建“移动视图”。
  4. 可单元测试 Silverlight还包括一个Unit Test框架。可以在此处下载：http://code.msdn.microsoft.com/silverlightut/
  5. 如果您没有运行IIS 7，则会遇到挑战 Silverlight不关心您是否在运行IIS 6或IIS 7，或者Apache。这是Silverlight比ASP.NET MVC更具优势的一个功能。
  6. 客户端缓存 在ASP.NET Web Forms或MVC中，您正在服务器上进行缓存。Silverlight允许您通过隔离存储在客户端上进行缓存（如果需要，可以将其增加到数百兆字节）。这使得应用程序能够快速执行，而不会使托管服务器变慢。

CONs与ASP.NET Web Forms

难以转换现有代码 Silverlight是一个完全不同的编程平台，与ASP.NET WebForms或MVC都不同。很多代码不仅无法转换，而且您还需要考虑客户端层，并且如果要替换现有的ASP.NET站点中的大型模块，则大多数情况下需要完全重新架构。
默认情况下并非最佳的SEO 几个月前Google开始爬行SWF文件并将其添加到搜索引擎中。我认为Silverlight在这方面可能还有一段路要走。对于Silverlight的SEO，您可以使用基本技巧，在插件周围很好地描述元数据标记。
数据访问 Silverlight中的数据访问仅限于Web Services/WCF/ADO.NET Data Services。您无法通过ADO.NET或存储过程直接调用数据库。
安全性 Silverlight在客户端上运行。因此，您的很多位元素会在互联网上漫游。此外，某些数据访问技术不支持完整的WS*标准安全性。因此，除了基于证书的传输安全之外，您要么自己编写大量的管道代码，要么等待下一个版本。XAML代码相当不安全；没有多少应用程序将其知识产权放在其UI中。在Silverlight中，可以使用Silverlight Spy等工具轻松地进行反向工程。显然，与ASP.NET MVC应用程序相比，Silverlight的安全性稍逊一筹。在将其放出之前，您肯定要加密/混淆您的Silverlight程序集。
1

1. Silverlight可以从托管页面访问DOM，
2. 托管页面可以访问Silverlight部分。
这对Silverlight来说是一个巨大的优势。

但所有其他限制都需要WPF/Windows-Forms 与Clickonce一起使用
文件访问、右键单击、易于访问数据库

0

如果您不需要全部使用WPF，我建议您先尝试使用Silvelight。这样，如果以后需要使用WPF，您就可以更轻松地切换。

在这里，我认为应该应用“少即是多”的原则：的确，使用WPF可以获得更多选项并访问用户计算机，但随着时间的推移，这可能会成为问题而不是帮助。例如，在使用大量“用户计算机”资源的应用程序中，您可能需要进行多次更改才能从Windows XP更改到Vista！

0
Mark，你说的“单一浏览器”是指什么？XBAP可以在Firefox等浏览器上运行。它确实需要.NET Framework，而且很可能我们不会很快（如果有的话）在Mono上拥有WPF，所以你只能使用Windows系统。
0

你可以增加在线与离线之争的优缺点。以下是一些内容：

优点

wpf（离线）：

  • 更好地访问计算机的低级部分。
  • CPU使用是本地的，所以你很少会遇到CPU负载问题。
  • 不依赖于网络。
  • 没有维护停机时间。

silverlight（在线）：

  • 更好地控制用户。如果你的用户登录，你就不必担心激活密钥或类似的东西。
  • 它适用于Windows和Mac。
  • 你可以轻松更新所有用户的应用程序。

我简化了一下，列表中还有一些灰色区域。我只玩过XBAP，所以我会留下它。在看完优点后，缺点并不难想出。

希望对你有所帮助。

一些好的观点！谢谢你。 关于“cpu使用率是本地的”。这对Silverlight来说也是一样的，不是吗？ - Mark
是的，用词不当。我的意思是当你有一个服务器时，你会遇到负载问题，但我太懒了，没有写出来 :-) - Artur Carvalho
0

我会考虑使用支持同步框架的WPF ClickOnce（www.msdn.com/sync）。这将允许您在用户未连接到公司网络时支持有限的功能（这将消除任何基于浏览器的部署方案，如Silverlight和XBAP）。

0
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接