一、Cairngorm框架的工作流程：
1. 前端控制器（FrontController）監聽用戶行爲
前端控制品是Cairngorm事件的唯一監聽者，但其不併做任何操作，只是集中註冊並管理事件（Event）與命今（Command）的映射關係。
2. 命令（Commands）執行所有用戶操作
前端控制品（FrontController）監聽到事件與命令有匹配時，便告訴命令（Commmands）調用execute()方法處理事件。
3. 服務器端業務邏輯委託給Business Delegate
當命令（Commands）執行時，它只是關心是否獲取到數據，而並不關心獲取到什麼具體數據。因爲經常需要從服務器端獲取數據，此時命令（Commands）更喜歡把它委託給其它類去操作。所以需要處理服務器端業務邏輯的時候，你都可以委託給命令（Commands）可以調用的 Business Delegate類去處理。
4. Business Delegate在Service Locator中尋找RPC Services
Business Delegate給命令（Commands）和RPC Services提供一個無縫接口。Business Delegate通過查找和匹配 PRC Services的名稱來調用services並返回結果給命令（Commands）。命令（Commands）要從Business Delegate獲取返回結果數據必須通過IResponder接口(mx.rpc.IResponder)，只有這樣Business Delegate才知道命命令（Commands）有onResult()和onFault()來處理返回的數據。
5. 把數據存儲爲Value Objecs
強烈推薦把數據存儲爲Value Objects。
6. 在Model Locator保存狀態並且讓Model通知View
Model Locator是一個保存應用程序全部狀態和包含Value Objects的地方。當應用程序狀態改變時，Moel Locator 通過Data Binding方式來通知View改變。
Cairngorm框架的工作流程存在如下主要問題：
二、Cairngorm框架的工作流程問題分析與解決辦法
該工作流程在實踐中的一個主要問題是Model Locator全局單例類，該設計將應用中的所有數據集中於Model Locator，有很多優點，也導致了衆多問題出現，如：
1. 靈活性低：相當於一個新的GOD類，知道應用中所有信息。而複雜應用中的衆多數據難以被一個GOD類包含。框架對Model Locator存在嚴重依賴，未來的變更將變得困難。
2. 問題測試困難：Model Locator對所有Commands公開，當出現數據問題時，難以檢查問題原因。
3. 數據校驗困難：View通過綁定刷新顯示，難以對數據進行檢查和校驗，從而也不能更友好的進行用戶提示。View不能直接得到數據，不方便對數據進行檢查和其他處理。
FLEX與Cairngorm框架學習使用心得體會
在學習的過程中，有些事情只需要學習怎麼做（know how）就行，有些事情必須知道爲什麼（know why）。這種有區分的學習方式是學習效率的重要保障。
一、 FLEX
1、 事件驅動
FLEX的事件驅動模型架構是基於Observer設計模式，以界面事件爲中心的。事件以消息形式按照組件層級進行廣播。組件如果訂閱了該事件，組件的事件處理方法被觸發。不同與BS的請求響應模式。
該事件體系分爲：
a) 事件觸發：可視化組件可以調用dispatchEvent方便的手工觸發事件。當然也可以在界面上操作以觸發事件。
b) 事件消息廣播：事件觸發後，觸發組件爲目標組件，以目標組件爲基點向父組件層層廣播，稱爲事件流。
c) 事件捕獲與處理：註冊了事件監聽器的組件的事件處理方法被觸發，開始執行事件處理。
d) 事件流控制：默認情況下事件層層廣播，直到最高層級的Application爲止。當然，也可以對事件進行如下控制：
i. 中斷：使用stopPropagation()和stopImmediatePropagation()中斷事件 流。中斷主要用於事件處理完成情況下爲避免父組件也接收到事件消息而出現不可預期的行爲。（合理利用中斷體現了開發人員對所開發軟件的控制力。）
ii. 僞裝：僞裝並非標準技巧。修改事件中的信息，可以將事件進行僞裝。主要用於改變控件的默認行爲。
iii. 變異：原事件流繼續，同時觸發新事件開啓新事件流，這爲FLEX代碼增加了無限的靈活性，也大大增加了理解難度。打開FLEX的源碼，可以看見很多。
事件驅動模型架構是FLEX開發的中心，沒有理解和掌握該模型架構，就不能妄談FLEX開發。FLEX中大量使用事件，導致代碼閱讀和理解存在一定困難，所以要學習FLEX必須先花大功夫熟悉事件驅動模型。
2、 動態化與反射
動態化和反射是靈活的開發框架必不可少的部分。FLEX的編譯機制也很有特點，只能編譯Application能夠訪問（靜態或者實例）到的類文件 才能夠被編譯進入SWF中。這種編譯機制有效的減少了SWF文件的大小，但是也有個比較大的缺點，就是動態代碼開發與運行成爲問題。
如果要開發一個靈活的可以二次開發的開發框架，需要有效利用動態化。
a) 將二次開發的代碼放入Application可訪問路徑。
b) 利用反射動態調用代碼。
3、 方法參數-函數式編程
FLEX另一個特點是方法參數，這點與常用的面嚮對象語言JAVA有明顯區別。有效使用方法參數將帶來巨大的靈活性，比如使用自定義方法改變控件屬性或行爲、回調callback。
方法參數與常用的面嚮對象語言JAVA有明顯區別，原面向對象編程的開發人員需加強理解。
4、 RPC異步調用
RPC異步調用其實也是事件驅動模型的一種應用。RPC調用是FLEX與遠程服務器通訊的方式，是企業應用程序中必不可少的部分。
RPC異步調用類似於AJAX異步調用，與平時習慣的請求響應模式的同步調用有很大區別。需要開發人員轉換思路加強理解。
二、 Cairngorm
Cairngorm是應用一系列設計模式和軟件開發實踐開發的FLEX企業應用微架構。其核心是基於FLEX的關鍵特徵和企業應用的架構模式。
1、 事件機制
Cairngorm在FLEX的事件驅動模型基礎上定義了一套新的事件驅動模型。FLEX本身的事件驅動模型可以認爲大部分是基於可視化控件的，FLEX的事件驅動模型的事件流是從目標控件開始層層向上傳遞知道Application的。
Cairngorm的事件驅動模型的構建是在Application層級用FController構建全局的事件監聽器。FController監 聽到Cairngorm事件後調用對應的Command。Cairngorm事件驅動模型的特點是：直接在Application層級，沒有多層傳遞。並 且一個事件對應一個Command一一對應。
Cairngorm的事件驅動模型適合於處理業務邏輯，也僅適合於處理業務邏輯。最好不要用Cairngorm事件來處理界面行爲。
2、 動態化與反射
Cairngorm沒有直接使用反射。但是遵循了FLEX編譯器的規定，在Application中引用FController和Service以保證所有Cairngorm的相關代碼均被FLEX編譯到SWF中，便於在應用中調用。
3、 MVC與多層架構
Cairngorm框架的一個重要特點就是其MVC的多層架構設計，其中FController是其MVC模式的關鍵控制器。看到有網友介紹Cairngorm的文章對此框架的首要調整就是去掉FCotroller，這就相當於沒有利用Cairngorm框架的最大優點。
Cairngorm框架對錶現層（View）劃分很清晰，View觸發事件，FController作爲控制器，提交到Command開始的業務邏輯層。
而業務邏輯層的劃分就不是那麼清晰了，因爲業務邏輯層是跨FLEX和後臺服務（如J2EE）的。有2種設計方式，第一種是可以大部分放在J2EE的 後臺服務層，Command、Delegate、Service都只作爲代理，這種更加類似與原BS多層架構的邏輯。另一種設計方式可以將業務邏輯全部放 在FLEX中，後臺服務僅作爲持久層，類似於CS雙層架構的邏輯。當然也有2種設計方式的混合，部分放在FLEX中，部分放在後臺服務中。業務邏輯層的設 計與分佈是最考驗架構設計師能力的部分。
4、 RPC異步調用
Cairngorm框架利用RPC異步調用與後臺服務通訊。在此處，性能設計是一個關鍵點，可使用的設計模式包括Facade模式。此處是FLEX與後臺服務的接口，接口處更考驗設計功力。
三、 總結
個人認爲，在對FLEX的學習過程中，思維模式的轉變很重要，尤其是要重視事件驅動模型、方法參數這兩個與J2EE等面向對象開發思想的轉變。這兩點一定要做到爲什麼（know why）。
在對Cairngorm框架的學習、使用乃至調整的過程中，事件機制和MVC模式必須做到爲什麼（know why），而動態化與反射和RPC異步調用僅需做到怎麼做（know how）就可以了。