RIA framework - Cairngorm 2 淺析

隨者 Itereation::Two被併入 Adobe 成為 Consulting Team與 Flex 2 /AS3 的面市，Cairngorm這個framework的正統性與普及性也跟者水漲船高，最近專為 Flex 2 量身打造的新版 Cairngorm v2 也剛放出來，所以早上花了點時間再 review一次，看看有沒有什麼大改變，本文就是一早研究心得的速記。

簡單來說，Cairngorm是一個framework，提供了許多現成的 class library、運作機制與template，目地是幫助工程師更有紀律的開發中、大型專案(by saying mid to large I mean 5-10 engineers in several teams and project time ranges from months to years)。

它的架構很單純，只有六大項

-business
-commands
-control
-model
-view
-vo

Cairngorm在最上層定義了六大塊的基礎結構，然後在每個 project 再 extends 後加入自已需要的功能，這也是大部份 framework 的玩法，例如 ARP, Struts, Cake等。

以 Cairngorm 2 內附的 login 例子來說，它的事件流程是這樣的：

1. 畫面上有 帳號、密碼兩個文字框與一個 login按鈕，當user按下 button時，form會將兩個文字欄位的內容打包成一個 LoginVO(Value Object)，然後將此事件廣播出去

2. 背景裏的 FrontController早先會先透過 addCommand()註冊偵聽這個事件，並且轉手將它交給 Command 處理

3. Command裏面只做兩件事，一是建立一個 delegate物件，透過它去連回server(細節請看下一步)，二是建立好 responder 物件，裏面有 onResult, onFault兩個 callback handler

4. delegate 則是真正跟 server連線傳接資料之所在(講的fancy一點就是它會連回 middle tier做資料交換與同步)，在這個物件裏面可以決定要用 remoting, web service, http get/post 等任何一種方式來傳遞，只要確定當結果回來時，要正確的 mapping回 responder裏面的 callback handler

5. 當 repsonder接到result後，就做後續的處理；在Cairngorm的設計裏，有一個叫做 ModelLocator 的 central storage，這個玩意基本上是個 Singleton Class，裏面放一堆程式執行期間要共用的變數與物件，以前大家都塞在 _global裏，後來 AS2時代我叫它 GlobalSettings (也有人叫它 SystemInfo)，總之意義都一樣，以這個例子來說，responder就會將接到的result更新到 ModelLocator裏面。

6、最特別的一點是在 ModelLocator被更新後，由於它裏面每個 member 都被設定為 binding，因此資料一改變，就會牽動所有bind到它身上的物件，例如 view的切換或 dataProvide的更新。

至此一個事件流程就跑完了。

這裏面比較有意思的地方有幾個：

-每個tier切割的很乾淨，甚至太乾淨了(你聽過水清則無魚吧？)，分工明確且單純，因此可以說是非常的 decoupling，對大型專案來說這是非常重要的。

-command 與 delegate 徹底分離，他的考量是這樣如果將來要從 Web Service 跳到 remoting甚至更炫一點的 Flex Enterprise Service時，只要換掉 delegate層就好，responder 的部份可維持不動。

-他善用 flex 2裏 event bubbling的特性，讓所有的事件都bubble到最上層的 Application後再集中做處理，只是這樣做的小麻煩就是一定要用自製的 event class去廣播才行。

簡單結論：

1、Cairngorm 是一個設計的想當不錯的framework，但實務上應用的機率實在不高，主要原因是他的優點也就是他的缺點。例如切割的太乾淨導致開發時間反而延長，對中小型的專案(五十萬以下二到三人合作)來說優點變成了負擔。

2、他有部份設計雖然乍看之下很 decoupling，但實作上卻會碰到難以避免的麻煩，例如 command 雖然設計美意是可重覆使用，但實際上每個案子的差異性卻會導致這種機率變的很低；另一個例子是 command 與 delegate分離，實務上當從 web service切換到 remoting時，如果傳回的資料結構與型態不同，勢必得將 callback handler重新寫過，所以一開始這樣的分離設計就是有問題的。

3、簡單講，想到每做一件事(例如 login)就要寫六個檔案(controller, command, delegate…)就覺得有點沒力，就算再自虐的 java工程師大概也不會想輕易嚐試，更別提如果這是在debug，光是trace到正確的檔案恐怕就得花六倍的時間。

正如古諺所云：Know the rules so you know what you are breaking.

知道有Cairngorm 這個東西還是挺不錯，至少知道那些地方可以吸收使用，那些地方可以再改良，更重要的是如果有一天真要上場處理超大型專案，至少也知道該從那裏下手使力(死道友不死貧道？）。

最後，做個小小民調：

你已經在使用 Flex 2 了嗎？(即使只是裝起來稍做把玩)
如果是，請留個言出個聲吧，真好奇在中港台三地已經有多少玩家們投入這個領域了。

下載網址

by jeremy