SCSF / CAB - 模块和查看加载最佳实践?

发布于 2024-09-14 09:43:04 字数 637 浏览 6 评论 0原文

我有一个团队正在 CAB/SCSF 上构建复杂的富客户端用户界面。我们正在考虑的设计元素之一是 CAB 模块以及可能的 CAB 视图本身的动态加载。利用“开箱即用”的 SCSF/CAB 将在启动时自动加载所有模块组件。我们的富客户端应用程序的启动时间很长,并且随着我们添加更多模块而增加。

我只是好奇其他人是否研究过 CAB 模块加载过程的标准开销。这一切都在 CAB 视图的加载中吗?如果是这样,是否有人考虑过为 CAB 视图设计一种“按需”加载机制,以便最大限度地减少模块装配加载占用空间?这里的想法是,在第一次真正需要视图之前,不应加载视图。在模块级别设计“按需”加载机制有什么真正的好处吗?

关于最佳实践的想法将不胜感激......

(请注意,这个问题最初出现在 http://social.msdn.microsoft.com/Forums/en-US/modelingandtools/thread/dce936fe-45f9-420c-90ca-286a8d553e35,所以我复制粘贴了丹写的问题)

I have a team who is architecting a complex rich client user interface on CAB/SCSF. One of the design elements we're considering is the dynamic loading of the CAB modules and potentially the CAB views themselves. Leveraging SCSF/CAB "out of the box" will automatically load all module assemblies at start-up time. The start-up time for our rich client application is significant and will grow as we add more modules.

I'm just curious if other folks out there have looked at the standard overhead of the CAB module loading process. Is it all within the loading of the CAB Views? If so, has anyone looked at designing an "on demand" loading mechanism for CAB Views, so that the module assembly-load footprint can be minimized? The idea here is that a View shouldn't be loaded until it's actually needed the first time. And are there any real benefits to designing an "on demand" loading mechanism at the module level?

Thoughts on best practices would be much appreciated ...

(Please note that this question originally appeared on http://social.msdn.microsoft.com/Forums/en-US/modelingandtools/thread/dce936fe-45f9-420c-90ca-286a8d553e35, so I have copy pasted the question written by Dan)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

残花月 2024-09-21 09:43:04

我们在应用程序中广泛使用 CAB,因为我们有非常复杂的 UI 和相应复杂的业务逻辑。在我们的例子中,使用 cab 确实会增加开销,因为框架不仅设置视图,还设置工作项的层次结构以及所有 ui 组件之间的连接。但我相信与实例化和加载所有对象和对象所需的时间相比,时间并不重要。我们的应用程序需要数据,尽管有一天我们需要彻底测试这个假设。

为了帮助我们管理加载时间并管理可用功能,我们
--> 有我们自己的配置管理器,我们可以用它来选择性地加载所需的模块
--> 允许仅在用户请求时而不是事先创建视图的设置
-->仅在手动刷新时延迟加载数据
--> 根据用户需求限制我们网络服务的数据输出的设置。

We use CAB extensively for our application, since we have a very complex UI and correspondingly complex business logic. In our case using cab does add overhead due to the framework setting up not only the views, but also setting up the hierarchy of workitems and also the wiring between all the ui components. But I believe that time is not significant compared to the time required for instantiating and loading all the objects & data needed for our application, though someday, we will need to thoroughly test this assumption.

To help us manage the loading time and also manage available functionality we
-->have our own configuration manager, that we can use to selectively load only required modules
-->settings that allow for views to be only created when a user requests them and not before hand
--> lazy loading data only on manual refreshes
-->settings to throttle data output from our network services based on user demand.

薔薇婲 2024-09-21 09:43:04

据我所知,模块加载并不需要太多时间。我们在 SCSF 上有两个企业级应用程序,其中一个源代码超过 700mb!它非常大,我们在加载模块时从未遇到任何问题。在创建视图之前,它不会在内存中实例化。有关模块中视图的信息已加载但未实例化。你的说法有点令人困惑。

我怀疑你们在第一次加载模块时执行了哪些服务调用或其他应用程序设置。

To my knowledge the module load doesnt take too much time. We had two enterprise level applications on SCSF, one of its source code is more than 700mb! its pretty huge and we never faced any issue in loading the module. And until the view is created it is not instantiated in memory. the information about the views in the module is loaded but not instantiated. Your statement is lil confusing.

I would suspect what service calls or other application setup you guys perform while the modules are loading for the first time.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文