所以我在相当大的LOB应用程序的概念证明阶段。该应用程序将部署到许多组织中的许多桌面（200+）。它将包含许多CRUD类型的屏幕（大约100个），以及一些非常复杂的过程，如发票生成和财务分类帐集成。它还将包含大量报告。
我已经完成了大量的功课，并且几乎已经确定了以下技术堆栈：
所有缺少的是表示层，所以我的问题是：
Silverlight 3是构建如此大型应用程序的合适技术吗？
最初我担心Silverlight缺少报告故事但现在有commerial reporting tool可用问题解决了。所以现在我想知道我的应用程序的大小以及当他们尝试在浏览器中下载时的性能。凭借100多个“屏幕”和大量报告，它无论如何都不会轻量化。
Silverlight 3是明智的选择还是我应该关注WPF？ SL3的主要原因是在许多组织中部署到大量桌面的问题。
答案 0 :(得分：7)
如果您的应用程序需要以下内容，我建议将Silverlight 3.0用于LOB应用程序。
只要您的发布频率合理，我认为这些好处将超过大型初始下载的副作用。
另一方面，如果以下任何一种情况属实，我会重新考虑使用Silverlight 3.0。
如果您保证是标准客户端，则可能需要探索“Click-Once”Windows应用程序。它克服了上述限制，不受“沙箱”的约束，您仍然可以使用Web部署模型。
答案 1 :(得分：4)
我们正在为5000多名用户进行SL3应用，但屏幕较少（30+），我们相信它是可能的。我们还为同等数量的用户提供4屏幕应用程序。如果您担心下载性能，可以做两件事：
答案 2 :(得分：2)
要使初始应用程序更小，您也可以按需加载XAML模块（即使它使事情变得复杂）。一般情况下，如果应用程序在使用它时响应良好（并且应该很好地适应SL3），用户不会介意som加载时间。也许另一种选择是带有ajax和SL3的.net，用于绝对需要的UI。
构建如此庞大的应用程序是一项非常新鲜的技术，但它应该是可行的。如果它的重量太重，那么可以通过创建不同的模块来解决它。请记住，保持在相同模块中逻辑上一起执行的工作任务。
答案 3 :(得分：0)
另外考虑到Silverlight运行时仅适用于Windows和Mac，因此如果您希望应用程序可以从Linux中的浏览器中使用，请忘记Silverlight。
（是的，我知道有Moonlight。但我不会把我的鸡蛋放在这个篮子上，除非微软决定参与这个项目。