flex cairngorm架構流程

一、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）就可以了。