CAB提供了一个非常灵活的编程框架，利用这一框架，可以很好的将一个应用分离成不同的模块进行开发。
    我们来看看一个基于CAB的典型应用都有哪几部分组成：

首先一个CAB应用需要通过继承自FormShellApplication的应用程序类来进行启动。FormShellApplication需要传入两个类型参数，继承自WorkItem的类,和继承自Form的类（应用程序主界面FormShell）。主界面上可以放置供所有界面视图使用的公共的UI Element (如：Toolbar)。和显示用户界面的WorkSpace。WorkItem是封装了用例实现的容器，容器中的对象可以共享信息。WorkItem也可以包含下级WorkItem.

由于CAB的优点之一是能够很好的支持模块化开发，业务开发人员可以专注于某一方面业务模块的开发，如：仓库管理系统中，入库和出库就是同一个系统中的两个业务点，在CAB的支持下，完全可以将这两个业务点交由不同的开发人员进行开发，只要按照同样的既定的规范开发（界面规范，接口规范等），就能很好地进行集成。CAB中通过Module很好的实现了这一点。

一般我们将module实现于dll文件中，每个Dll文件可能包含系统某一方面的功能，当我们在独立开发好各个Module之后，我们可以利用CAB有选择的加载这些功能模块，从而支持系统运行。要实现Module被加载很简单，只需要在ProfileCatalog.xml中将需要被加载的module配置进去就可以了。当然前提是被加载的模块需要符合CAB的Module设计的标准。如图中所示，这个dll中需要有一个继承自ModuleInit的类，Module被加载的时候，该类的Load方法将被调用，所以大家也可以在继承类中通过重载Load方法来扩展其加载时的行为。

一般情况下，在独立的模块中，我们还需要实现相应的继承WorkItem的类来实现其业务用例的封装，这个WorkItem我们需要将其添加到RootWorkItem的WorkItems集合中，以便和其建立联系。

在WorkItem中可以使用MVP的模式来实现我们的系统。上图中的View是在主窗体的WorkSpace中显示的和用户进行交互的界面，Presenter则是响应界面操作，处理业务逻辑的地方，Model则是我们的数据。

虽然我们的系统可以模块化的独立开发，各个模块之间实现了松耦合，但是系统运行时，CAB还是需要通过某种方式将各个模块糅合在一起，以便形成一个有机的整体。首先CAB是一个IOC的容器，它可以在运行时根据需要实例化各种对象，并将其注入到对其有需要的对象中，达到对象的组装，然后可以通过发布订阅事件系统及共享State实现了对象间的通讯。

CAB涉及的Dll有：
   
    常用的命名空间如下：
    
    附两张CAB中命名空间Microsoft.Practices.CompositeUI和Microsoft.Practices.CompositeUI.Winforms涉及的类和接口：
       
   

个人认为，CAB是的不错的WinForm应用框架，目前主要还是体现在对界面层和业务逻辑层的支持上。如果配合其他的技术框架如Nhibernate对数据库层进行支持，将会更好。