Silverlight 是否适合大型 LOB 应用程序
因此，我正处于一个相当大的 LOB 应用程序的概念验证阶段。该应用程序将部署到许多组织的许多桌面（200 多个）上。它将包含大量 CRUD 类型屏幕（大约 100 个），以及一些相当复杂的流程，例如发票生成和财务分类账集成。它还将包含大量报告。
我已经做了很多功课，并且基本确定了以下技术堆栈：
- PRISM
- CSLA
- NHibernate
所缺少的是表示层，所以我的问题是：
Silverlight 3 是构建如此大型应用程序的合适技术吗？ ？
最初我担心 Silverlight 缺乏报告故事，但现在有了 商业报告工具可用，问题就解决了。所以现在我想知道我的应用程序的大小以及当他们尝试在浏览器中下载它时的性能会怎样。拥有 100 多个“屏幕”和大量报告，无论如何它都不会是轻量级的。
Silverlight 3 是一个明智的选择还是我应该考虑 WPF？ SL3 的主要原因是部署到许多组织中的大量桌面的问题。
So I'm at the proof of concept stage for a fairly large LOB application. The application will be deployed to many desktops (200+) in many organisations. It will contain lots of CRUD type screens (around 100), along with some pretty complex processes like invoice generation and financial ledger integration. It will also contain lots of reports.
I've already done lots of homework and pretty much settled on a technology stack of:
- PRISM
- CSLA
- NHibernate
All that's missing is the presentation layer and so my question is this:
is Silverlight 3 an appropriate technology to build such a large application?
Initially I was concerned about the lack of a reporting story for Silverlight but now there is a commerial reporting tool available that problem is solved. So now I'm wondering about the size of my application and what the performance will be like when they try to download it in their browser. With 100+ "screens" and a whole load of reports it isn't going to be lightweight by any means.
Is Silverlight 3 a sensible option or should I be looking at WPF instead? The primary reason for SL3 was the problem of deploying to lots of desktops in lots of organisations.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您的应用程序需要以下功能，我建议将 Silverlight 3.0 用于 LOB 应用程序。
只要您的发布频率合理，那么我认为这些好处将超过大量初始下载的副作用。
另一方面，如果满足以下任一条件，我会重新考虑使用 Silverlight 3.0。
如果您保证使用标准客户端，您可能想要探索“单击一次”Windows 应用程序。它克服了上述限制，不受“沙箱”的约束，您仍然可以使用Web部署模型。
I would suggest Silverlight 3.0 for a LOB application if your application requires the following.
As long as the frequency of your releases is reasonable, then I think that these benefits would outweigh the side-effects of a large initial download.
On the flip side, I’d reconsider using Silverlight 3.0 if any of the following are true.
If you are guaranteed a standard client, you may want to explore a ‘Click-Once’ Windows application. It overcomes the above restrictions, is not bound by the ‘sandbox’, and you can still use the web-deployment model.
我们正在为 5000 多名用户开发 SL3 应用程序，但屏幕较少（30 多个），我们相信这是可能的。我们还在为相同数量的用户制作 4 屏幕应用程序。如果您担心下载性能，您可以做两件事：
We're doing an SL3 application for 5000+ users but with less screens (30+) and we beleive it's possible. We're also in production with 4 screens app for same amount of users. If you're concerned about download performance you can do two things:
为了使初始应用程序更小，您还可以按需加载 XAML 模块（即使这会使事情变得复杂）。通常，如果应用程序在您使用时具有良好的响应（并且这应该非常适合 SL3），那么用户不会介意一些加载时间。也许另一种选择是使用 ajax 的 .net 和 SL3，用于绝对需要的 UI。
构建如此大的应用程序是相当新鲜的技术，但它应该是可行的。如果它的重量太重，那么可以通过创建不同的模块来解决。还要记住，将逻辑上一起执行的工作任务保留在同一模块中。
To make the initial application smaller you can load XAML modules on demand also (even if it complicates things). Generally users won't mind som loading time if the application has good response when you are working with it (and that should fit SL3 nicely). Maybe another alternative would be .net with ajax and SL3 for the UI where it's absolutely needed.
It is quite fresh technology to build such a big app, but it should be doable. If it gets too heavy weight then it can be solved by creating different modules. Remember too keep worktasks that's logically performed together in the same modules.
还要考虑到 Silverlight 运行时仅适用于 Windows 和 Mac，因此，如果您希望应用程序可以通过浏览器（例如 Linux 机器）使用，请忘记 Silverlight。
（是的，我知道有 Moonlight。但我不会把鸡蛋放在这上面除非出于某种不明原因微软决定参与这个项目。）
Take also in account that the Silverlight runtime is only available for Windows and Mac, so forget about Silverlight if you want your application to be usable from a browser in, say, a Linux box.
(Yes, I know that there is Moonlight. But I wouldn't put my eggs on this basket unless for some obscure reason Microsoft decides to participate in this project.)