Cairngform vs. Puremvc

Cairngorm

Cairngorm是Adobe官方提供的一個MVC Framework，要瞭解它，可以直接閱讀Adobe Developer Center裡面，收錄的Develop Flex RIAs with Cairngorm microarchitecture六篇文章，在閱讀時，要配合第一篇文章提供的範例程式Cairngorm Store對照來看，會比較清楚，我是使用Cairngorm Store (non J2EE Container version)。只要讀者有J2EE Patterns的基礎，就能夠瞭解Cairngorm，因為Cairngorm的設計沿襲了部份的J2EE Patterns，再加上它自己的一些設計。

雖然我看過J2EE Patterns，但是閱讀這六篇文章還是花了不少力氣，原因在於RIA介面的複雜性。在Web-Based的J2EE裡面，網頁的元件跟後端程式的互動，都是靠Front Controller來處理，所以後端只要用一個Servlet就可以作為前端發送到後端命令與參數的入口（可再配合Command來將互動的指令分類處理），單一的入口簡化了前後端的互動，資料傳送到前端後，整個畫面都是重新產生的，資料流很單純地只有一條路徑。

到了Flex就不一樣了，因為都是產畫面上的元件後，再將資料餵進去的，所以一個地方的元件資料異動，可能會同時影響到其他地方的資料（像是AJAX的網頁也有類似的問題），所以在後端傳送資料回去到前端時，元件互動的處理就非常麻煩了，所以Flex才有了Bindable這種東西。

Cairngorm已經存在了兩年了，又是官方的產品，很多專案都是使用這個framework，但它的複雜，也讓開發人員誤認為，flex actionscript是很難以親近的一種語言，雖然Cairngorm身為MVC框架的正規軍，部份設計理念也來自於J2EE，但它也繼承了J2EE複雜。

Puremvc

另一個MVC Framework: Puremvc，它定位自己為一個純粹地，與語言無關的輕量級MVC Framework，很多人都推崇這樣一個設計單純的框架，但是在官方網站上能找到的文件，除了一個看起來像天書的Best Practice，一個Conceptual Diagram與一個UML設計圖，就沒有了，找不到很簡單的tutorial或是step by step的說明。

在瀏覽過文件跟一些blog的說明後，我發現，我得用另一種更有效率的方法來瞭解Puremvc，就是從PureMVC Standard for AS3的Demos，直接從程式碼來了解應該怎麼使用它。

在trace過AppSkeleton、CafeTownsend、Slacker、EmployeeAdmin、StartupAsOrdered之後，我才算是比較瞭解Puremvc了，例如：(1) 畫面切割後，以ViewStack來切換 (2) 畫面上的動作，先產生flash.event.Event之後，在初始化Mediator的時候addEventListener，處理完該動作後，就sendNotification (3) 每一個ViewComponent都對應了一個Mediator專責處理 (4) ApplicationFacade裡面要 initializeController，並在裡面registercommand，StartupCommand裡面要 registerProxy 與 registerMediator (5) Notification sender有 Command、Mediator、Proxy，receiver有 Command與Mediator

除了標準版外，還有Multicore版本，差別在於，Multicore的Facade裡面有一個HashMap，所以必須要以key為參數，取得Facade，也就是return instanceMap[key] as ApplicationFacade。目前並不是非常瞭解Multicore版本要用在哪裡，但網站裡提供了Pipes、Startup Manager與State Machine這幾個Utilities，Startup Manager是用來處理動態載入資源的過程，透過它可以取得載入的狀態與進度，Pipes看起來像是處理模組之間的訊息，但實際上的用途，我還沒看懂。

Cairngorm vs. Puremvc

Why I think you shouldn't use Cairngorm提出了五點說明，希望大家審慎評估要不要使用Cairngorm。我在看過之後，真的是覺得Cairngorm非常的複雜，但是已經存在了兩年了，又是官方的產品，如果要進入這個世界，對整個team來說，負擔很大，並不是每一個人都能讀懂J2EE Patterns之後，再讀懂Cairngorm。

結果當然是採用Puremvc，跟Cairngorm比較起來，package跟class都變少了，只要有按照固定的邏輯撰寫程式，程式變得比較容易讀了。一個簡潔的框架，才能適當地幫助Programmer減輕負擔，而不是一個龐大的框架，成堆的專有名詞，讓人沒辦法很快地進入狀況。

用了一陣子之後，發現了2個問題，第一個是我們發現很少用到Command，大都是Facade、Mediator、Proxy跟Notification就可以把整個AP做完，至於Command到底應該用在哪裡比較恰當，這個我還在思考中。另外還有個問題是，Constants並沒有固定的位置，範例大都是寫在ApplicationFacade裡面，但似乎切割獨立成一個單獨的class會比較恰當，或者應該把Naming convention的規則記錄下來，這樣對於專案來說或許會比較健康一些。


thoughts about Cairngorm (again…)