您对 MS CAB（复合应用程序块）有何看法？
我正在评估 CAB 在新的 .net 3.5 winform 项目中的使用情况，
我计划使用 Infragistics 工具集，众所周知，“CAB 兼容”
虽然 CAB 的直接好处是让我专注于我的业务，而不是编写基本的对接/登录/等代码，但我觉得我能够我自己相当迅速地实现了相同级别的功能（当您“拥有”代码时，您会获得额外的灵活性/反应性奖励）。
我正在向使用 Microsoft CAB 的人寻求一些反馈：
- 您遇到过问题/错误吗？
- 您觉得 CAB 节省了您的时间吗？
- 是否还有我不知道的额外功能（除了对接/登录/WorkerThreads 最佳实践之外？）
I'm in the process of evaluating the use of CAB for a new .net 3.5 winform project
I plan to use the Infragistics toolset, which is known to be 'CAB compliant'
While CAB has the immediate upside of letting me focus on my business instead of coding basic docking/login/etc code, I feel like I would be able to achieve the same level of functionnality quite radpidly by myself (with the added flexibility/reactivity bonus you have when you 'own' the code).
I'm seeking some feedback on Microsoft's CAB from people using it :
- Have you experienced problems/bugs ?
- Do you feel like CAB saved your time ?
- Are there extra functionalities I don't know about (beside Docking/Login/WorkerThreads best practices?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
几年前我有一些使用 CAB 的经验，我的结论是它太复杂并且学习曲线陡峭。 因此，它所提供的好处根本不值得付出加快速度的代价。 然而，不要相信我的话，尝试遵循他们的一些实验室，看看你的想法。
Jeremy Miller 撰写了一系列关于构建您自己的 CAB 的精彩博客文章
http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-own-cab-series -table-of-contents.aspx
这些值得一看，因为您可以从那里获取您需要的内容。
我的建议是继续你的项目，而不是预先构建一个框架。 随着项目的发展，您应该发现将代码重构为基类的机会，并从您的应用程序中有效地收获框架。
这样，您最终将得到一个满足您需求的框架，并且开发团队中的每个人都会理解。 无论你做什么，都不要预先构建一个框架 - 这就是通往毁灭的道路:-)
I had some experience using CAB a couple of years ago and my conclusion was that it too complex and had a steep learning curve. As such the benefits it offered just weren't worth the price of getting up to speed with it. However don't take my word for it, try following some of their labs and see what you think.
Jeremy Miller wrote an excellent series of blog posts about building your own CAB
http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-own-cab-series-table-of-contents.aspx
these are worth a look as you could just take from there what you need.
My advice would be to get on with your project rather than build a framework up front. As the project develops you should spot opportunities to refactor code into base classes and effectively harvest a framework from your application.
That way you will end up with a framework that meets your needs, and that everyone on the development team will understand. Whatever you do don't build a framework up front - there lies the path to ruin :-)
我们已经在几个项目中使用了 CAB+SCSF。 学习曲线确实很陡。 第一个月后您可能会熟悉情况。
其他缺点：
优点：
遵循业界最佳实践架构设计模式：
从长远来看，使用 CAB-SCSF 将意味着更少的错误和更易于维护的代码。 如果您的项目能够承受学习曲线的初始冲击，我肯定会推荐它。
We have used CAB+SCSF for a couple of projects. The learning curve is indeed steep. You will probably be up to speed after the first month.
Other cons:
The pros:
Follows the best practices architectural design patterns in the industry:
Using CAB-SCSF in the long run will mean less bugs and more maintainable code. If your project can afford the initial hit of the learning curve I will definitely recommend it.
CAB 已停用，取而代之的是 SCSF。 CAB 和 SCSF 在跨项目标准化富客户端开发方面都提供了一些价值（如果您以这种方式使用它们），但两者都非常重量级。
The CAB is retired in favor of the SCSF. Both the CAB and SCSF offer some value in terms of standardizing rich client development across projects (if you use them that way), but both are very heavyweight.
虽然我从未真正使用过 CAB，但它随源代码一起提供，因此如果您需要应用程序块未提供的额外灵活性，您仍然可以对其进行调整以满足您的具体需求。
While i've never actually used CAB, it ships with the source code so you'd still have the ability to tweak it to suit your exact needs if you need extra flexibility not provided by the Application Block.
我们在 CAB 框架上构建了我们的企业应用程序，但修改了它的许多部分以满足我们的需求。
从这次经验中，我可以看出，当您需要非常灵活的模块化架构，并且 UI、业务逻辑和数据层的开发之间有明确的划分时，CAB 更适合。
CAB 确实有其缺点，即生成大量代码，有时会导致开发人员使用复杂的机制来实现简单的结果（例如过度使用事件发布/订阅模型、即使是最简单的 ui 的 mvp 模式……）
。关于这一点，有一个由 Rich Newman 撰写的精彩系列，位于
http://richnewman.wordpress.com/intro-to-cab-toc/< /a>
如果您只想使用依赖注入/控制反转，则使用托管扩展性框架 (http:// mef.codeplex.com/），可能是一个非常好的轻量级替代方案。
We have build our enterprise application over the CAB framework, but have modified many parts of it to suit our needs.
From that experience, I can tell that CAB is more suitable, when you need a very flexible and modular architecture and there is clear division between development for the ui, business logic and the data layer.
CAB does have its disadvantages of having lot of generated code and sometimes induces developers to use complex mechanisms to achieve simple results (like overuse of the event publication/subscription model, mvp pattern for even the simplest ui, ...)
If you want an introduction to this, there an excellent series by Rich Newman at
http://richnewman.wordpress.com/intro-to-cab-toc/
If you only want to make use of Dependency Injection/Inversion Of Control, then Managed Extensibility Framework (http://mef.codeplex.com/), can be a very good, lightweight alternative.