关于c＃：Silverlight，Wpf Web应用(xbap)或单击一次？ 利弊


Silverlight, Wpf Web App (xbap) or Click Once? Pros and Cons

我们正在开始一个新项目，我正在尝试确定应该使用哪种Wpf风格的开发/部署策略。在我们的案例中，我们正在研究一个相当复杂的商业应用程序，该应用程序将被数百人(而非1000人)使用，因此，我倾向于单击一次应用程序。我的老板喜欢Silverlight应用程序的想法，因为它意味着更容易部署。那么我们应该跳哪条路呢？

答案当然是"取决于"。
那么每种优点和缺点是什么？

我将开始滚球(编辑来自artur carvalho的一些答案)：

银光

  • 优点

跨浏览器
不需要完整的框架。
更好地控制用户。如果您的用户登录，则不必担心激活密钥或类似内容。
它适用于Windows和Mac。
您可以轻松更新所有用户的应用程序。

  • 缺点

无法与客户端的文件系统等交互
与完整的Wpf相比功能更少(任何人都有很好的资源来记录差异吗？)
单窗
单版

WPF Web应用程序(xbap)

  • 优点

全Wpf。

  • 缺点

单一浏览器
需要完整的框架
无法与客户端的文件系统等交互
单窗
单版

Wpf单击一次

  • 优点

全WPF
可以离线工作
多个窗口
多个版本(con？)
更好地访问计算机的底层部件
无需停机维护

  • 缺点

单一浏览器
需要完整的框架
稍微难安装？

相关讨论

首先，我将评估Web客户端(理想情况下为MVC + jQuery)是否无法完成工作...

假设有正式客户：

如果这是一个需要客户的业务应用程序，那么我倾向于使用完整的框架和ClickOnce；这里(重新部署)的主要区别是客户端必须安装框架-但除此之外，ClickOnce部署非常轻松。实际上，构建一个ClickOnce清单要比Silverlight等容易得多，因为IDE几乎可以为您完成所有操作。您只需要将文件托管在某个位置(可以是Web URL；可以是网络UNC)。

这样，您可以在客户端获得更多控制(和功能)，并可以使用更多范围的现有资源(例如，如果需要，可以在WPF界面上使用一些旧版winform代码)。"需要完整框架"也是最大的好处之一："具有完整框架"。

您也许还应该考虑3.5"客户端配置文件"的设置；不知道这在现实中有多广泛...但是值得了解。

您没有说这是公司专用的应用程序还是面向公众的应用程序。仅此一项将为您决定。

如果仅是公司，我将使用完整的WPF单击一次。这将为您提供一切。
完整的框架应该不是问题。这是一次在后台运行的安装，因此您的决定不应该依赖它。缺点：它仅在Windows中运行，但是如果您的公司仅是Windows，则应该没有问题。

但是WPF应用程序可能会占用大量资源，因此您需要知道所有客户端计算机是否都能平稳运行WPF应用程序。

如果是Internet应用程序，请使用Silverlight：它在不同的操作系统上运行。

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

但是所有其他限制都对带有Clickonce的WPF / Windows-Forms哭了
文件访问，单击鼠标右键，可轻松访问数据库

专业人士与ASP.NET Web表单

  • 没有ViewState或"惊讶废话"
    o这也适用于Silverlight。 Silverlight将"桌面"体验带给最终用户，并且Silverlight中没有使用ViewState。
  • 更快的服务器端和客户端
    o Silverlight在客户端/服务器端更快，具体取决于您的外观。 Silverlight在Silverlight的.NET子系统中进行编译。您可以访问多线程，LINQ，复杂的数据结构等。与ASP.NET或AJAX / JavaScript应用程序相比，由于客户端执行以及通常在服务器BLL中处理的某些项目，因此性能要好几倍。可以带给客户
  • 多个相关视图的简化模型
    o Silverlight支持数据和UI的完全分离。通过为另一个Silverlight使用者创建单独的视图来进一步扩展此功能非常强大。您可以在Silverlight中应用相同的MVC / MVP模式，并达到此抽象级别。杰森(Jason)提到了一个示例，它能够为iPhone创建单独的视图，而仅视图组件必须更改。这也适用于Silverlight，适用于不同的事物。例如，我有一个想要移植到SharePoint的大型Silverlight应用程序。我可以为SharePoint创建一个"更小视图"，使其更适合UI。此外，Silverlight Mobile现在正在接受私人测试。我假设同样非常强大的抽象水平也适用于为您的Silverlight应用程序创建"移动视图"。
  • 可单元测试
    o Silverlight还包括一个单元测试框架。可以在这里下载：http://code.msdn.microsoft.com/silverlightut/
  • 如果您没有运行IIS 7，将面临挑战
    o Silverlight不在乎您是否不在IIS 6或IIS 7或Apache上运行。这是Silverlight优于ASP.NET MVC的一项功能。
  • 客户端缓存
    o在ASP.NET Web窗体或MVC中，您正在服务器上进行缓存。 Silverlight允许您通过隔离存储(在必要时可以增加到数百兆)在客户端上进行缓存。这使应用程序可以超快速地执行，而不会阻塞托管服务器。

    • 缺点与ASP.NET Web表单

  • 难以转换现有代码
    Silverlight是一个与ASP.NET WebForms或MVC完全不同的编程平台。不仅许多代码都不会转换，而且还必须考虑客户端层，并且在大多数情况下，如果要替换现有ASP.NET站点内的大型模块，则需要完整的重新架构。
  • 并非开箱即用的最佳SEO
    o谷歌数月前开始抓取SWF文件并将其添加到搜索引擎中。我认为Silverlight可能仍然离这里很远。您可以为Silverlight SEO做的事情是基本描述插件周围元数据标签的基本技巧。
  • 资料存取
    o Silverlight中的数据访问仅限于Web服务/WCF/ADO.NET数据服务。您不能通过ADO.NET或存储过程直接调用数据库。
  • 安全
    o Silverlight在客户端上运行。然后，您的很多位都在互联网上漫游。此外，某些数据访问技术不支持完整的WS *标准安全性。因此，除了基于证书的传输安全性之外，您还可以编写大量自己的管道代码或等待下一次修订。 XAML代码几乎是不安全的。很少有应用程序具有其UI中的知识产权。例如，在Silverlight中，可以使用Silverlight Spy非常轻松地对其进行反向工程。从本质上来说，Silverlight比ASP.NET MVC应用程序的安全性差一点。显然，您需要对Silverlight程序集进行加密/模糊处理，然后再随意使用它们。

    • 优点

    好的。

  • Silverlight插件意味着开发人员可以为基于浏览器的应用程序指定一个一致的运行时，而不必处理不同版本的多个浏览器的复杂性。尽管Adobe Systems的Flash具有相同的优势，但您还可以获得纯HTML和JavaScript很难或无法实现的视频和多媒体效果。
  • 在不部署.NET运行时的情况下执行.NET代码。 Silverlight插件确实包含一个简化的.NET运行时，但用户无需下载大量文件和Windows安装程序的复杂性，而是只需约4MB的较小下载量，即可在浏览器中处理。到目前为止，根据我的经验，安装过程很顺利且容易。
  • 性能是有希望的。 Silverlight在这个质数计算器中表现出色，这毫无疑问要归功于JIT对本机代码的编译，尽管在渲染图形方面可能不那么出色。
  • 对Moonlight的支持意味着将有Silverlight的官方开源实现，从而减轻专有方面的影响。
  • Silverlight直接解释XAML，而Adobe的XML GUI语言MXML在编译时转换为SWF。实际上，XAML页面作为资源包含在用于部署Silverlight应用程序的已编译.XAP二进制文件中。 .XAP文件只是具有不同扩展名的ZIP。这也意味着搜索引擎可以像在Flash中一样在Silverlight应用程序中为文本建立索引。
  • 第三方组件供应商已经很好地使用Silverlight附加组件。例如，Infragistics，ComponentOne和DevExpress。
  • 使您的.NET代码跨平台。随着Mac到处弹出，将Visual Basic或C＃代码迁移到基于浏览器的跨平台Silverlight客户端的能力将越来越有用。显然，这仅适用于现有的.NET开发人员-我猜这是Silverlight的主要市场，但这是一个很大的市场。下一点同样如此：
  • 使用Visual Studio。微软的IDE是一个成熟且受欢迎的开发环境，并且由于它也是ASP.NET的工具，因此您可以将其用于服务器端代码以及Silverlight客户端。对于不熟悉Visual Studio的用户，Silverlight SDK还支持命令行编译。
  • 选择你的语言。自开始以来，对多种语言的支持就一直是.NET的一部分，并且在Silverlight 2.0中具有.NET运行时意味着您可以使用C＃，Visual Basic或动态语言运行时(DLR)Iron Ruby来编码客户端逻辑。或Iron Python。
  • 隔离存储为Silverlight应用程序提供了本地文件访问权限，但仅在特定于该应用程序的受保护位置提供了相对安全的方式来获得此好处。

    • 缺点

    好的。

  • 如果Apple甚至不允许iPhone上使用Flash，那么Silverlight有什么机会？
  • Silverlight迟到了。 Flash已成熟，广受信任且无处不在。 Silverlight 2仅在秋季发布beta版本(我们希望如此)。它是我们关心的版本-包括.NET运行时的版本-仍将缺乏对移动设备(甚至Windows Mobile)的支持，尽管以后会有一些未指定的承诺。
  • 设计工具是Expression Blend和Expression Design-但是谁使用它们？设计界使用Adobe PhotoShop。
  • 虽然Expression Blend和Visual Studio之间具有解决方案兼容性，听起来不错，但实际上却很麻烦，必须使用两个单独的工具，尤其是当存在不兼容的问题时(如当前Beta)。
  • 不支持流行的H.264视频编解码器。相反，用于Silverlight的高清视频必须使用VC-1，这种情况不太常见。
  • 推广专有技术而不是开放标准是另一项努力。
  • 是的，将通过Moonlight支持Linux，但是何时？ Linux实施似乎总是会落后于Windows和Mac版本。
  • Silverlight支持SOAP Web服务或REST，前提是您不使用PUT或DELETE，但没有像Adobe的ActionScript Message Format(AMF)这样的优化二进制协议，这在某些情况下可能会降低性能。
  • Silverlight是仅浏览器的解决方案，而可以使用Adobe Integrated Runtime(AIR)将Flash部署到桌面。话虽如此，是的，我已经看到了。
  • 您必须在Windows上进行开发。这对于Expression设计工具尤其成问题，因为设计人员拥有数量不成比例的Mac。

    • 好。

    这些天，通过此插件，单击一次就无法在firefox上使用了：https://addons.mozilla.org/en-US/firefox/addon/1608

    马克，对XBAP说"单一浏览器"是什么意思？例如，XBAP确实适用于Firefox。它确实需要.NET Framework，而且我们不可能很快在Mono的任何地方(如果有的话)在WMon中安装WPF，因此您必须使用Windows，这是正确的。

    如果不需要所有WPF，我将首先尝试在Silvelight中进行操作。如果以后需要，可以更轻松地切换到WPF。

    在这里，我认为它采用了"少即是多"的原则：的确，使用WPF，您可以有更多的选择并可以访问用户计算机，但是随着时间的流逝，最终这最终将成为一个问题，而不是帮助。例如，考虑一下在使用大量"用户计算机"资源的应用程序中，需要从Windows XP更改为Vista的更改数量！

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

    您可以添加在线辩论与离线辩论中常见内容的优缺点。一些项目：

    优点

    wpf(离线)：

    • 更好地访问计算机的低级部分。
    • cpu的使用是本地的，因此很少有cpu负载问题。
    • 不依赖于网络。
    • 无需停机维护。

    silverlight(在线)：

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

    我简化了一点，列表中有灰色区域。我只修改了XBAP，因此我将忽略。在寻找专业人士后，不难发现缺点。

    高温超导

    相关讨论