因此，我正处于相当大的LOB应用程序的概念验证阶段。该应用程序将部署到许多组织的许多桌面（200+）。它将包含大量的CRUD类型的屏幕（大约100个），以及一些非常复杂的流程，如发票生成和财务分类账集成。它也会包含很多报告。Silverlight是否适用于大型LOB应用程序
我已经做了很多功课，并付出很大的技术栈解决：
唯一缺少的是表示层所以我的问题是这样的：
是Silverlight 3 an适当的技术来建立如此大的应用程序？
最初我担心缺少Silverlight的报告故事，但现在有一个commerial reporting tool可用，该问题已解决。所以现在我想知道我的应用程序的大小，以及当他们尝试在浏览器中下载它时的性能。有了100多个“屏幕”和一整套报告，它不会以任何方式轻量化。
Silverlight 3是一个明智的选择，还是应该看WPF呢？ SL3的主要原因是在许多组织中部署到大量桌面的问题。
如果您的应用程序需要以下内容，我会针对LOB应用程序推荐Silverlight 3.0。
只要你发布的频率是合理的，那么能力我认为这些好处将超过大量初始下载的副作用。
另一方面，如果以下任一情况属实，我会重新考虑使用Silverlight 3.0。
如果您有担保的是标准客户端，您可能需要探索'Click-Once'Windows应用程序。它克服了上述限制，不受“沙箱”的约束，您仍然可以使用Web部署模型。
我们正在为5000多名用户做一个SL3应用程序，但屏幕较少（30+），我们相信这是可能的。我们也在为4个屏幕的应用生产同样数量的用户。如果你担心下载性能，你可以做两件事情：
为了使初始应用程序更小，您还可以按需加载XAML模块（即使它使事情复杂化）。一般来说，如果应用程序在使用它时有很好的响应（并且很适合SL3），用户不会介意som加载时间。也许另一种选择是.net与ajax和SL3的UI在绝对需要的地方。
构建这样一个大应用程序是相当新鲜的技术，但它应该是可行的。如果它的重量太重，那么可以通过创建不同的模块来解决。请记住，保持在相同模块中逻辑执行的工作任务。
另外考虑到Silverlight运行时仅适用于Windows和Mac，所以如果您希望您的应用程序可以从Linux中的浏览器使用，请忘记Silverlight。
（是的，我知道有Moonlight，但我不会把我的鸡蛋在这个篮子除非出于某种模糊的原因微软决定参与这个项目。）
我还要补充，因为只有Windows客户端！作为第一条件。 – 2009-10-22 18:44:05
Silverlight也运行在MacOS X上。对于Linux，你可能想看看Moonlight – 2009-10-30 08:28:03