3，Composite UI Application Block (CAB) 結構介紹

     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對資料庫層進行支援，將會更好。