因此，我正處於相當大的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