Cairngorm
Cairngorm是一個廣爲人知的老牌Flex框架。它是一個微型架構——由一些設計模式組成用來降低團隊協作的困難。
Cairngorm從Java的世界帶來了很多開發理念，並且把重點放在三個關鍵區域：處理用戶動作，封裝服務端的交互和業務邏輯，管理客戶端的狀態和界面呈現。
使用Cairngorm來構建一個項目，需要將應用代碼分離到不同的包並且繼承Cairngorm的類。以下是Cairngorm項目中一些主要的部分和類。
- ModelLocator是一個儲存數據的單例，數據表示程序的狀態。單例類的性質保證了程序中的所有組件取得的是相同的數據。
- ServiceLocator是另一個單例，它集中管理所有服務如HTTPServices。同樣，由於是單例，程序中的所有組件取得的是相同的服務。
- 業務邏輯被封裝在command類中。command實現了命令模式，它們表示相應用戶事件的邏輯。
- 事件被類FrontController處理，FrontController會把事件映射到相應的Command。
- Delegate類作爲代理來對遠端服務進行請求和響應。
優點
Cairngorm在Flex社區廣爲人知，作爲Adobe開源項目的一員，擁有活躍的社區和開發者的支持。
其次，該框架吸取了Java開發中許多寶貴的經驗，併成功得用於大型項目的開發中。
並且，Cairngorm適用於團隊開發，因爲它提供了結構化的開發方法來創建應用，利於分佈式的開發。
缺點
需要寫大量的類應該是Cairngorm最多的負面評論了。在Cairngorm中，每一個event對應一個command；因此，需要對程序觸發的每一個事件來寫一個command類。而且，還要爲command寫一些其他的類，例如delegates。即使是一箇中型的應用也會導致大量的類產生。
其次,Cairngorm實現了自己的一套事件處理的方法。這增加了Flex內置事件模型的複雜度，而且它還有限制。由於每個事件都有自己的的command，事件的響應者被限制成1個。加之Cairngorm的事件不具冒泡特性，如果要發送數據到容器的其它層次則需要自己來實現。
第三個常見的批評是Cairngorm依賴全局的單例，這讓模塊和單元測試變得困難。儘管可以打破單例中的模型簡化測試，但是會增加額外的過程。
資源
- Cairngorm developer documentation
- Developing Flex RIAs with Cairngorm microarchitecture – Part 1: Introducing Cairngorm (Steven Webster and Leon Tanner, August 2008)
- Example Cairngorm project
Mate
Mate是一個基於標籤的，事件驅動的框架。基於標籤意味着它可以完全實現在MXML中。該框架的目的是讓事件響應者的聲明變得簡便。
在項目中使用Mate只需要處理兩個方面：使用1個或者多個事件，有一個成爲”event map“的MXML文件——被包含在主程序中的一個MXML文件。它定義了需要監聽的事件以及如何被處理。必須有1個event map，而且允許有多個。
Mate也實現了依賴注入（Dependency injection）的理念——有時被稱爲好萊塢原則,或 “don’t call us, we’ll call you”。對象的創建時這樣一種方式：數據被創建並且注入到對象中。也就是說，對象不會喊着要數據（”don’t call us”），而是數據被傳送給對象（”we’ll call you”）。
優點
Mate使用依賴注入提升了鬆耦合性。因爲組件不依賴全局的單例，能更自由地作爲對立的部分。Mate不會阻止你使用Flex內建的事件機制，也不會像Cairngorm一樣爲每個事件都使用單獨的響應。Mate的MXML標籤文件簡單易用，而且文檔優秀，在官網上有大量的代碼實例。
缺點
Mate使用MXML文件構建，要是作爲一個ActionScript開發者，就需要調整自己的習慣。而且Mate沒有爲應用程序制定結構，這份工作留給了開發者。
因此，需要加強團隊協作來保證代碼的兼容性。還有一個問題與Adobe LiveCycle Data Services ES有關，要知道Mate暫時還不能處理LiveCycle Data Services提供的數據管理方面的功能。
資源
- Mate documentation
- Example projects
- Podcast interview with Mate framework creator Laura Arguello
PureMVC
儘管PureMVC用在Flex上，但是它並不是只爲Flex設計的。PureMVC的創建者想讓它是一個語言無關的框架。如果你訪問它的網站，會發現大量的不同語言的實現版本。
PureMVC以MVC模式爲中心，其目標是把項目分離成模型層，視圖層和控制層。這三個層表現爲三個單例——Model，View和Controller，還有第四個單例Facade用來對前三個單例進行集中管理，是Facade模式的實現。
與Cairngorm很像，使用PureMVC創建一個項目需要把項目分成多個包，然後繼承框架中的類來構造自己的類。最後還要爲項目額外創建一個Facade類來作爲程序的入口。
優點
與Cairngorm一樣，PureMVC是一個結構良好的框架，有活躍的社區和開發者支持。它很適合團隊開發，其清晰的結構能告訴開發者如何創建和組織代碼。
缺點
因爲它依賴於單例，所以有着和Cairngorm一樣的缺點。它不是一個特定的Flex框架，所以沒有充分利用到MXML的特性。
跟Cairngorm類似，PureMVC有自己的事件處理方式，但是跟標準的Flex事件模型一起工作會增加開發難度。
PureMVC是一個比較複雜的框架，有相當陡的學習曲線。除非你的團隊很熟悉它，否則培訓會佔用很多時間。
還有，PureMVC也需要創建很多類，既增加了產品的開發時間，又增大了項目的尺寸。
資源
- Documentation and licensing
- Example project
- Podcast interview with PureMVC framework creator Cliff Hall
Swiz
Swiz是一個控制反轉（IoC, Inversion of Control）框架，它提供一些機制來簡化事件處理和異步遠程調用。Swiz的真正意圖是以一種簡單高效的方式提供一個MVC範式。與Cairngorm和PureMVC不同，它借鑑了Java的一些模式，摒棄了預定義的文件結構。
使用Swiz創建一個項目需要告訴Swiz所用到的組件。以這個爲核心，Swiz是一個集中管理的工廠模式。組件被名爲BeanLoader的靜態類加載到工廠當中，由工廠來處理組建的實例化。
Swiz還提供依賴管理，它使用了一個名爲Autowire的自定義標籤，Autowire標籤定義依賴然後交給Swiz處理。
優點
Swiz簡單易用，沒有預定義的文件結構。類似於Mate，Swiz通過Autowire這個依賴注入系統，提升了鬆耦合性。也類似於Mate，它使用Flex內建的事件模型，並且使用單例來發送一個關鍵的事件。
缺點
跟Mate一樣，Swiz沒有爲項目的結構做過多的定義，這些留給了開發者，因此，需要加強團隊協作來保證代碼的兼容性。
其次，它使用了自定義標籤，項目的建立會額外多出一些步驟，例如設置額外的編譯選項。這些過程並不複雜，但是至少這些過程在其他框架中不需要。文檔強調的是Flex 2的開發者，所以可能不適合比Flex 2更新的版本。
資源
- Documentation and examples
- Podcast interview with Swiz framework creator Chris Scott
做出選擇
雖然描述的並不詳盡，但是這些信息加上資源足以讓人理解提到的每個框架的方法論，優點，還有缺點。看了這些，你將如何作出取捨呢？
也許第一個問題應該問：我是否需要一個框架？Flex和MXML爲快速應用開發提供了健全的系統和方法。我一直以來不太使用框架的原因是，相對於使用Flex框架而言，使用額外的框架會讓我爲了適應這些框架而去做更多的事情。我認爲，框架的作用是簡化工作任務和提高生產率，而不是爲了證明我能用或者用了就說明我是一個優秀的開發者。
在一個電話面試中，我解釋了自己爲什麼選擇不使用框架，面試者回應：”我們是一個大的團隊，所以你明白爲什麼我們需要一些框架了”。一番思索之後，我確實明白了它的意思。
使用框架的一個好處就是它讓代碼的編寫標準化了。一個程序員A和一個程序員B使用同一個框架負責同一個項目的兩個不同部分，那麼可以認爲他們寫的程序是兼容的。也許這時候應該考慮另一個問題：有多少結構允許被強加？
這裏介紹的這些框架或多會少都包含了一些預定義的結構。與獨自開發相比，團隊開發需要更多這樣的結構。這些結構可以增加項目的開發時間和文件尺寸，但是也會提升團隊的開發環境和代碼的一致性。相比這下，如果你是項目唯一的開發者，就不需要把事情搞那麼複雜，或許你需要一個沒有這麼多預定義結構的框架。
所以，選擇一個正確的框架或者壓根不用框架是由開發環境和項目決定的。我能給出的最好的建議是瞭解你的項目。通過我的調查和這篇文章，我認爲自己對框架的看法會更深刻，它們確實可以滿足一些需求。