Composite Application Library(CAL)
1，一個Composite Application 的基本組成
Composite Application Library（CAL）作為Composite Application Guidance的最重要的組成部分，為我們提供打造Composite Application的最基礎的組件和服務。
看看下面這張圖
一個Composite Application通常由這些部分組成的（與此同時，CAL相應的為我們提供了這些基礎組件）
Shell：應用程序的頂級窗口，其Host了各種不同的UI組件（通常是View），Shell本身並不知道它包含了哪些內容，通常情況下它有這非常有限的功能，而其他絕大多少功能則是由各個Module來提供的
Shell Presenter：Shell的表示層邏輯，和MVP模式中的Presenter的意義相同，這使得Shell易於測試和維護
Region：其相當於一個占位符，用於Host可視化元素（其被放在View中，並通過Region Manager來訪問）
Module：由View，數據模型，業務邏輯，服務等組成的一個集合，也就是我們常說的“模塊”，其易於被單獨開發、測試和部署，通常情況下我們讓不同團隊成員甚至是不同的團隊負責不同的模塊，然後這些模塊最後再被集成起來成為一個完整的應用。
View：即“視圖”，與MVP中的View意義相同。
Service：應用程序或模塊暴露一些用於共享的“服務”，這些服務會被一個成為“服務容器”的東西來進行定位和加載（在CAL中其為Unity Container）
2，創建一個基於CAL的Composite WPF Application
如果應用比較復雜的話，我們一般會將應用劃分成不同的模塊，然後再用一個Shell Project來將這些模塊組織起來，我們來看看如何使用CAL來做到這一點的。
看看下圖：
定義一個Shell：
Shell為程序主界面提供基礎的布局，這些布局由Region來定義（或者說來占位），然後其他模塊可以向Region注入視圖（View或其它可視化元素）。通常情況下，Shell還會包含一些應用程序的基礎樣式（Style）等以便為應用程序提供統一的風格。
Shell、View、Region之間的關系可以參考下圖
創建Bootstrapper
每個應用程序都有一個自己特有的Bootstrapper（其繼承於UnityBootstrapper）來定義一個如何枚舉其模塊的策略（比如，按照靜態引用的方式來枚舉其各個模塊，還是用一個配置文件來配置各個模塊，該配置文件與CAB的ProfileCatalog.xml文件類似）
通常情況下，UnityBootstrapper會啟用所有的CAL基礎服務，但我們可以通過禁用或替換這些服務來定制更適合我們應用程序的Bootstrapper。
另外，Bootstrapper提供了日志功能，其采用的是.NET TraceWriter，但我們也可以在Bootstrapper中來定制自己的日志。
更多的，可以參考下圖
創建Module
從語法層面上講，我們需要實現IModule接口來創建一個Module。另外，Module還會負責將該模塊中的View注入到Shell或其他模塊的Region中去。
在Composite Application Guidance for WPF中我們更多的可以看到采用MVP模式來創建的Module。關於Composite Application Guidance for WPF中的MVP模式，我會在該系列隨筆的後續文章中講到。
部署Composite WPF Application
基本上跟部署普通的WPF桌面應用差不多（Installer，ClickOnce），但有時會有一些新的問題，由於我們可以采用較松散的方式來來組織各個模塊（比如采用配置文件）而使得模塊之間沒有直接引用關系，這會導致一些打包工具不能自動查找關聯模塊來打包，為此CAL提供了一些工具和技術來解決這些問題。
