thoughts about Cairngorm (again…)
最近三不五時得跟 Cairngorm 這個 framework打交道，原因是大部份國外客戶與專案都在用它，結果每個合作的工程師見面第一句都是：
-you know Cairngorm, don’t you ?
-we are using Cairngorm on this project, if you are not familiar with it, ….
(通常是給個鏈結要人去看 devnet 上的 Cairngorm六篇教學)
所以在形勢比人強的情況下，就算我心裏再怎麼不認同Cairngorm，也只好忍痛傷害一下腦細胞開始用了。
正好昨天 Cairngorm 的創始人 Steven Webster 寫了一篇 Why I think you shouldn’t use Cairngorm，裏面解釋了在何種情況下，你不應該使用它。
這篇文章讓我想起累積許久的想法，就順便整理一下。
＊好處
-protocol:
總的來說，大底而言 framework 的功用就是為了讓軟體開發過程中，能有一個共同的標準、手法與依規，例如相同的底層架構，程式邏輯分割等，而 Cairngorm 做的就是這樣的事。
因此它就像是一個 protocol(通訊協定)，一旦制定出來，大家就有一個標準可遵從，例如 pop3 protocol定義好後，大家都知道只要透過socket 連接再送出某些字串，就一定可順利與server溝通，而如果沒有這樣一個 protocol，那就會變成大家各搞各的獨門創意，最後就沒辦法普及。
所以如果大家都用某個framework(不一定要是 Cairngorm )，那工程師間的溝通或系統分析與設計就會變的比較簡單，因為就像 UML 一樣，大家用相同的符號與概念在做同一件事。
而這就是目前 Flex 2 開發 RIA 的現況。基於某些神奇的因素， Cairngorm 被認為是 Flex + RIA 的不二法門，不管新手、老手都一致認定要開發 RIA 就是先學會 Cairngorm 。
從某個角度講，這也是好事，因為當大家都熟悉這個 protocol 後，將來的確是走到那裏都可以直接 join 專案，不需重新熟悉別人的 coding pattern。
-de-coupling:
Cairngorm 在底層架構的設計上確實是切割的很乾淨，這點在我之前幾篇相關文章中已多次說明，它將每個tier 間的關系徹底分離，所以理論上 coupling 的情況是很低的，而某些元件，例如 command, service 也的確有可能在不同的專案間重覆使用。
＊壞處
-太複雜:
Cairngorm 主要的壞處，也正是它好處的反面，就是切割的太細導致編程手續變的很複雜，一個 user gesture 可能要透過五個class 才能達成。
如果你從來沒用過 Cairngorm ，這裏舉一個小例子，以login window為例，當user填好帳號、密碼後按下 submit 鈕，接下來會發生的事：
1. submit button handler 偵聽到按鈕按下的事件
2. 透過 CairngormEventDispatcher 廣播這個事件
3. Front Controller 聽到這個事件性轉手交給 command object 處理
4. Command 依事前指定的條件呼叫 delegate object
5. Delegate 物件透過 ServiceLocator 操作遠端呼叫
6. 當app server傳回result後再循反方向將 result 傳回 command
大部份新手看到這種手法大概就昏了，這還是以能看得懂為前提，而就算看懂，敢真的用到實際專案上的大概就沒幾個了。
這種過於複雜的流程導致新手難學，尤其在中小型的案子上更不適用，但許多工程師並沒有查覺這點…
-hurt flex:
Cairngorm 原先只是 Iteration::Two 這家公司提出的一個實驗性想法，但在 Adobe 買下它之後，一夜之間Cairngorm 似乎就成為 Flex RIA 的聖經、王道。
在大家的吹捧與討論之下(任何時候你到 flexcoders 上都會看到一堆Cairngorm相關問題)，讓許多 developer 以為這就是唯一的選擇，就像幾年前大家以為用java開發web application 就一定是用 struts，而沒有想到自已的能力、團隊、專案性質是否真的需要？
而這種情況造成的嚴重後果現在已然浮現，也就是大家以為
flex = cairngorm = 複雜難學
意思是，大家以為要用 flex 要先學 Cairngorm, 但 Cairngorm本身太複雜難懂手續又繁雜，因此，Flex 一定也是同樣的複雜難懂所以乾脆不要用它好了。
這種類推就好比 gmail 那天掛了，大家就怪 python, javascript 與 dhtml 不好，但這實在是非戰之罪啊~
現在 Adobe 也感覺到這種危機，當初推 Cairngorm 是為了打動企業用戶，讓主管們心安，知道世界上有一個類似 struts的 frameworks 可供開發超大型企業級RIA，但結果猛虎出柵後就尤如潘朵拉的盒子開啟，出去就收不回來，搞到最後不該用的人也跑來用，然後被 Cairngorm 燒到就怪罪到Flex 頭上，最後就變的 Flex 也很難推，這就是現在Adobe 開始擔心的事。
這也是為何 Steven 會寫那篇文章，並且特別強調，在用Cairngorm之前，應該要先對 Flex 本身有徹底的瞭解，才能有足夠的能力判斷自已是否需要使用這個 framework。
＊解決之道：
我一直在思考這件事可能的解決之道。
幾個可能的方向整理如下：
-很不幸的，任何一個認真的 Flex developer 都一定要會 Cairngorm，並且至少用它開發過一個application, 原因就如上所言，它已經是一個官方欽定的開發手法並流通於全世界(就像英語一樣)，因此除非你不需要跟外界合作，不然的話早點摸熟工師程的共同語言是有益無害的。
-Cairngorm 並不是完全不可用，但一定要清楚知道它只是眾多framework 之一，不代表神聖而唯一的絕對，實際上當摸熟它之後，許多時候應該要理智的質疑它的缺點然後想出改善之道。(套一句 b6s 長輩的說法，這應該叫做”潛入其內、使其自爆”吧？)
-對大部份中小型專案來說，難道不能有一個更簡單易用的framework 嗎？答案是絕對有，畢竟 design pattern, best practices 大家都瞭然於心，這些是基本的大原則，掌握原則後應該可以自行依實際需要變通並設計出適用的”手法”。
＊後話：
從過去幾年的 RIA 開發過程中，我們已逐漸累積並形成一套簡易的開發規則，它不算是一個framework, 而比較像是 best practice 的集合，但已証明很適合用在 Flash/Flex 為主的專案開發，速度很快且手續簡便，大部份的工作都可以在三個steps內完成，但仍然保持每個 tier 間的 decoupling 與 彈性。
未來有空時我會製作一個小型的範例程式來示範這個手法，並嚐試說明每個環節的設計理念，屆時也歡迎大家從正反兩面來檢視這個手法，看看它有什麼優缺點。
ps. 目前範例只製作到一半，也還沒寫文件，但如果有興趣想先看看的朋友歡迎留個言，我會email給你，但希望你看完後至少要提供一些意見，例如你觀察到那些問題、缺點，or better yet, 可以提供改良的意見讓它更好。
29 Comments Add your own
1. shen14&hellip | August 23rd, 2006 at 9:19 pm
我先要哈，先谢过。
Cairngorm 观望一段时间了，觉得理解其中的过程比使用更重要，很多处理的手法还是很有学习价值的，就像你的范例一样，期待哈。
2. jeremy&hellip | August 24th, 2006 at 12:44 am
ok, 等我把整個例子寫完就寄給你。
3. saicn&hellip | August 24th, 2006 at 8:51 am
我感觉，Caingorm总的来说，也并不是非常之复杂。
4. realonlyjj&hellip | August 24th, 2006 at 9:38 am
这东西好,也要,学习一下,先谢了
5. jeremy&hellip | August 24th, 2006 at 9:45 am
to saicn: 這樣想好了，當案子規模變的很大(大約是數十個views 與 幾百個class時)，每個 user gesture 都會對應到八個steps, 而一個 view大約有十來個gestures時，整體的結構就會變的非常龐大。
這還不考慮個別implement 手法的差異，如果team中有人用了獨門的改良手法加入了奇怪的規則，事情就會變的更有趣了。
所以複雜，在這裏指涉的對象有許多種，有開發時的手續 與 debug時的難易度 以及新團隊成員加入時的門檻高低。
不過當然，說歸說，該用時還是就硬者頭皮上了，我最近每天邊寫都邊在想一句話: “出來跑，總是要還的啊” Orz
6. cmanwalking&hellip | August 24th, 2006 at 10:00 am
前辈方便的话给我一份。
我想说的是自己单独做一个（从实践中）是否有必要？
7. fantasysin&hellip | August 25th, 2006 at 9:47 am
想请教一下，用flash/flex开发RIA应用，用哪方面的web技术比较好呢。(php?cf?asp?java?.net?…)这里的好可能笼统了点，具体就是简便性，功能的强大以及可移值等的综合性价比.
8. tiankong&hellip | August 25th, 2006 at 6:09 pm
可以给我发一份吗？想学习下！谢谢！
9. Cames&hellip | August 25th, 2006 at 10:57 pm
老師我也非常需要sample。
不過基本上，我個人不認同Caingorm
因為實在複雜。
就如同struts與hibernate的信徒。
做什麼都要用這些技術。
但等專案後續修改時，才發現，也許這不是最佳的策略。
有些東西，簡簡單單反而更好。
開始懷念起C語言與Perl。
簡單實用，
可能才是現在programer要去追求
10. -TMA-1- » links for&hellip | August 27th, 2006 at 8:20 am
[...] d.CAT- the RIA blog » thoughts about Cairngorm (again…) (tags: Tech Flex Cairngorm Framework Development) [...]
11. jeremy&hellip | August 28th, 2006 at 12:40 am
to Cames:對啊，有個朋友跟我講(他對 cairngorm的看法): seems they are solving some problems that doesn’t exist ! 這也是一開始我就不採納 cairngorm 而另尋門路的原因。
目前上課中的RIA班正好範例做到一半，預計這星期五課程結束時就會有完整的範例，屆時將文件與說明加上去就會寄給所有留言與來信的朋友。
12. jeremy&hellip | August 28th, 2006 at 12:49 am
to fantasysin:
關於那個後台比較好，這確實是個大問題，還是要看你的project類型性質來選擇比較好。
但幾個簡單的想法：
1、php 是直譯式語言，結構也較鬆散，開發速度非常快也幾乎可在所有平台上執行，所以大部份中小型專案我都用 LAMP + amfphp 就解決掉。
2、做國外大型專案時，通常業主的選擇是 java，這大概是源自企業資訊系統主流的選擇影響，因為 Flex 畢竟是用於商業軟體居多，而這類公司內主要的人才通常不是用 java 就是 .net，因此往往沒得選。
3、如果你的app將來會需要 clustering 或 messaging，那最好一開始就用 java，這樣後路最廣(一部份考量是如果可能會用到 FDS)。
不過我的心得是，不管後台用那種語言，最熟練的那種就是最好的，畢竟掌控度高開發起來才順手。
而如果你問的是想長期投入flex開發工作的話，該學那種語言比較好，那最安全明智的選擇就是 java。
13. Satan404&hellip | August 28th, 2006 at 11:36 am
我也想要一份來學習一下
在下也是個Flex新手
有稍微看了一下Cairngorm
他的觀念是很好沒錯（分層分的很詳細）
不過就真的是有點給人一種小題大作的感覺
這有點像是寫個HELLO WORLD
還要找要用哪一種design pattern
以上為個人淺見…
14. Satan404&hellip | August 28th, 2006 at 12:02 pm
Sorry我忘記留下mail了…
15. saicn&hellip | August 28th, 2006 at 12:38 pm
jeremy，我也要一份你的samples，记得给我发哦。
就如你所说，其实我们在使用cairngorm的时候，一般都是由做稍微的修改来使用的，就类似那个rpc呼叫结果的IResponder。。。
16. hiso&hellip | August 29th, 2006 at 1:57 am
hi sir,
我也要一份samples!! THX!!
17. y31x&hellip | August 29th, 2006 at 11:14 am
新手，学习ing… 请老师发一份samples
18. david&hellip | August 29th, 2006 at 5:59 pm
目前正在學習中,也請發一份Sample供我參考.
19. fan,bill&hellip | September 3rd, 2006 at 6:44 pm
jeremy 可否也給我一份範例.
謝謝……
20. fan,bill&hellip | September 3rd, 2006 at 6:54 pm
請問 jeremy ，
Flex Framework 有用過那些、那一個比較好?
下面是查到的.
1. Cairngorm
2. Haxe frameworkd
3. FXT - Flex Templating
21. jeremy&hellip | September 3rd, 2006 at 11:58 pm
今天剛結束在高雄週未的課程，花兩天14小時將flex重要的功能與開發手法帶過一遍，也完成了一個加強版的範例程式，理想情況內下星期一、二應該就可完成中文說明與圖示，然後就會寄出給所有留言的人。
to Fan,
除了 cairngorm 外目前市面上應該沒其它專為 flex 設計的framework了，Aral Balkan 的 ARP 可以勉強套用到flex身上但它設計理念跟 cairngorm 類似所以同樣不盡理想。
在條件許可的情況下(例如我有權力掌控、主導專案或能威脅利誘其它工程師)我都會用自已設計的手法開發flex，經過一段時 間試驗，到目前為止反應都還算良好。
這也是我想進一步開放給大家測試的原因，多一點人玩玩比較有機會經由同儕檢視出可能的缺點或提供改進意見
22. VickLee&hellip | September 4th, 2006 at 6:24 pm
jeremy老師…
我是你高雄的學生(坐後面胖胖的那一個)…
可否也給我一份範例…
謝謝老師…
23. henry&hellip | September 6th, 2006 at 10:32 am
请教个相关FLEX的问题，我一直尝试通过Script来创建
WebService对象，但创建后都不能调用。
难道非要通过mxml的方式来描述WebService?这种描述方式过于分散不利于维护和扩展。
如果能直接继承于WebService来建立相关的Logic Interface比较理想，然后内部初始所有方法等。可惜对Flex不了解，相关帮助文档也没有描述通过Script创建WebService的例程。
24. jeremy&hellip | September 6th, 2006 at 11:46 am
透過 as3 調用 web service 失敗的原因有很多，可以先確定一下是不是 flash player security 在搗蛋，例如你要call的 ws 跟 swf 原本的 domain 不同，如果是這樣，放一個 cross domain policy xml 應該會有幫助。
另一個研究如何透過 script 調用 ws 的方式就是看 mxmlc codegen 自動產生的 code，你可以下一個 compiler 指令: –keep-generated-actionscript 就可以看到 compile 完後自動產生的code，裏面就會有它如何將一個 mx:WebService tag 轉換為 as3 code的手法。
25. henry&hellip | September 6th, 2006 at 2:07 pm
谢谢前辈，问题解决了。
不过有些事情实在是让人费解！
通过Script操作WebService,必须在Applicaton的initialize事件实例化；如果在其他地方或使用前才实例则调用无效；WebService实例化后也必须调用initialized方法。
26. jeremy&hellip | September 8th, 2006 at 12:48 am
to 所有留言的朋友：範例與中文說明文件皆已寫好，目前正委請本站大長輩過目兼校稿中，最快星期五即會寄出。
這是第一版的draft，希望收到信的朋友們能不吝指教多多提供改進意見，讓下一版更完美
27. duiduifei&hellip | September 13th, 2006 at 1:42 pm
能给我发一份吗?很想学一下!
28. hljlgj&hellip | September 18th, 2006 at 9:36 pm
我也要一份例子，谢谢！
29. jeremy&hellip | September 19th, 2006 at 2:30 pm
範例已正式公佈，請看這篇
Trackback this post | Subscribe to the comments via RSS Feed