Silverlight 是否适合大型 LOB 应用程序答案

【问题标题】：Is Silverlight appropriate for a big LOB applicationSilverlight 是否适合大型 LOB 应用程序
【发布时间】：2009-10-22 11:35:21
【问题描述】：

所以我正处于一个相当大的 LOB 应用程序的概念验证阶段。该应用程序将部署到许多组织的许多桌面（200 多个）上。它将包含许多 CRUD 类型的屏幕（大约 100 个），以及一些非常复杂的过程，如发票生成和财务分类帐集成。它还将包含大量报告。

我已经做了大量的功课，并且几乎确定了以下技术堆栈：

缺少的只是表示层，所以我的问题是：

Silverlight 3 是否适合构建如此庞大的应用程序？

最初我担心 Silverlight 缺少报告故事，但现在有一个可用的 commerial reporting tool 可以解决问题。所以现在我想知道我的应用程序的大小以及他们尝试在浏览器中下载它时的性能。拥有 100 多个“屏幕”和大量报告，无论如何它都不会是轻量级的。

Silverlight 3 是一个明智的选择，还是应该改用 WPF？ SL3 的主要原因是部署到许多组织中的大量桌面的问题。

【问题讨论】：

【解决方案1】：

如果您的应用程序需要以下内容，我建议将 Silverlight 3.0 用于 LOB 应用程序。

只要您的发布频率合理，那么我认为这些好处将超过大量初始下载的副作用。

另一方面，如果以下任何一项属实，我会重新考虑使用 Silverlight 3.0。

如果保证您是标准客户端，您可能想要探索“Click-Once”Windows 应用程序。它克服了上述限制，不受“沙盒”的约束，仍然可以使用网络部署模型。

【讨论】：

【解决方案2】：

我们正在为 5000 多个用户开发一个 SL3 应用程序，但屏幕更少 (30+)，我们相信这是可能的。我们还在为相同数量的用户生产 4 个屏幕应用程序。如果您担心下载性能，您可以做两件事：

【讨论】：

【解决方案3】：

为了使初始应用程序更小，您还可以按需加载 XAML 模块（即使它使事情变得复杂）。通常，如果应用程序在您使用它时响应良好（并且应该非常适合 SL3），那么用户不会介意加载时间。也许另一种选择是带有 ajax 和 SL3 的 .net 用于绝对需要的 UI。

构建这么大的应用程序是相当新鲜的技术，但它应该是可行的。如果它变得太重，那么可以通过创建不同的模块来解决。请记住，将逻辑上一起执行的工作任务保留在相同的模块中。

【讨论】：

【解决方案4】：

还要考虑到 Silverlight 运行时仅适用于 Windows 和 Mac，所以如果您希望您的应用程序可以在浏览器（例如 Linux 机器）中使用，请忽略 Silverlight。

（是的，我知道有Moonlight。但我不会把我的鸡蛋放在这个篮子上，除非出于某种不明原因微软决定参与这个项目。）

【讨论】：