介紹
最近，我進行了很多次的Adobe Flex
開發職位的面試（作為自由職業，這點需要澄清，如果我現在的老板碰巧閱讀到該文的話）。幾乎每一次的面試，Flex框架的問題最終都會被提出來（通常就是
Cairngorm）。我就會解釋盡管我知道這些框架的存在，但是我從沒有真正的去用它們。這個決定看起來對我來說足夠理智，但是這些不能給面試帶來深刻
的印象。我開始厭倦因為我的“對Flex框架缺乏經驗”而失去項目，我展開了一項任務僅我所能的去學習它們。
非常巧，本地用戶組的下一次聚會提到了Flex框架的話題，具體提到Cairngorm,
Mate以及PureMVC(你可以在這里看觀看)。我時常在Flex
show播客上聽到所有的這些框架，但是從來沒有真正的意識到他們是如何運作的以及他們之間的不同，本文的目的就在于指出這些。
本文提供了當前最流行的Flex框架，你可以根據了解來選擇最適合你的團隊或者項目的需求的框架。本文覆蓋了
Cairngorm、Mate、PureMVC以及Swiz 框架。我特意選擇了這些框架是因為它們已經被Flex show
播客提及并且或者已經被類似360|Flex 的會議所提出。
要求
完成本教程, 您需要安裝以下軟件和文件:
Flex Builder 3
必備知識
讀者需要知道什么是Adobe Flex。當然，如果讀者對框架涉及的內容有基礎的了解，對面向對象編程原理以及設計模式的基礎了解的話，對于閱讀本文那就更有幫助了。
Cairngorm 框架
Cairngorm是已知的最為古老與最好的Flex
框架。它實際上是一個微架構——它提供了一系列已經被證明可以很好的互相協作的設計模式的集合。Cairngorm采用累來自Java開發世界的笨重并且
把焦點集中到了三個關鍵區域：處理用戶行為，包裝服務端交互與業務邏輯，并且管理客戶端狀態以及在用戶界面（UI）上體現客戶端狀態。
在Cairngorm構建一個項目包含了拆散你的應用到若干個包中并且擴展Cairngorm的類。如下是一個Cairngorm 項目 主要包含的部分和類。
- ModelLocator —— 作為數據存貯角色的單件——反映程序的狀態。單件類的性質抱枕了程序中所有的組件都訪問相同的數據。
- ServeiceLocator 是另外一個單件，它作為集中存貯例如HTTPService的服務的角色存在。同樣，因為該類是一個單件，所有程序中的組件都會訪問相同的服務。
- 業務邏輯被包裝到了實現了命令模式的Command類中。這些類描述了程序響應用戶事件的邏輯。
- 事件會被FrontController 類處理，它會針對事件來執行相應的command類。每個程序可以回應的用戶事件都必須被注冊到它所附和的command類。
- Delegate 類會被用來做遠端服務訪問與反饋的代理。
優點
Cairngorm是Flex社區中眾所周知的，并且是一個Adobe 開源網站上的項目，有良好的支持并且一個活躍的開發者社區繼續為它工作。此外，它借用了來自Java開發世界的已被證明的策略。最后，它非常適合團隊開發，因為它提供了一個高級的結構化的一套方法來允許分發任務進行創建應用。
缺點
或許對Cairngrom做出的最多的批評就是它需要你去寫非常多的類。在Cairngorm中，每個事件映射到一個Command；因此，你不得
不為每個在你的應用中可以被觸發的事件寫一個對應的command類。另外，你必須要寫其他的command必須用到的其他類，例如delegate。這
會快速的增加一個小型應用的類的數量到一個巨大的數字。
第二，因為Cairngorm 實現了它自己的處理事件的方法，這個會把內建的Flex
事件模型變得錯綜復雜。它也有其他一些限制。因為每個事件都必須要有它自己的command類，你就被限制只能為每個事件提供一個響應器
（responder）.并且，Cairngorm事件并不會冒泡，所以如果你想要通知其他更高一級的容器，就只能自己來處理了。
第三條普遍的批評就是框架依賴于全局單例，讓想要模塊化和單元測試變的困難。雖然你可以從數個單例中破壞這個框架模型讓這些處理簡單些，但是額外的工作需求會復雜化流程。
資源
Mate 框架
Mate 是一個基于標簽的事件驅動型框架。基于標簽意味著它可以完全使用MXML實現。事件驅動使框架的主要焦點放在更簡單的來定義事件的回應。
使用Mate來創建項目只需要兩個基礎的必要條件：
你必須有一個或多個事件，以及你必須有一個成為“事件映射”的MXML文件——其實就是在主要的應用程序文件中包含了一個簡單的MXML文件。它定義了你
想要監聽的事件以及這些事件該如何被處理。你必須至少有這些文件中的一個，在需要的情況下也可以使用多個事件映射。
Mate也實現了依賴注入的思想 ——有時，適用于好萊塢原則，即
“不要給我打電話，我們會打電話給你們”.對象被這樣構造出來：需要的數據會被供給或者注入到類中。也就是說，類不去呼叫外部獲取數據（即“不要給我打電
話”），而是接受他們所需要的數據（即（“我們會打電話給你們”））
優點
Mate
通過它對依賴注入的使用實現松耦合。因為組件不用依賴全局單例，對場景來說他們是自由人。Mate不限制你使用Flex的內建事件模型，也不會像
cairngorm一樣限制你每個事件都要一個單獨的響應處理。Mate
的MXML文件以及標簽直接并且便于使用，同時如果你卡住了，它提供了不錯的文檔并在網站上有大量的代碼范例。
缺點
Mate只使用了MXML。所以，如果你是那種做每件事都喜歡使用ActionScript類的人，那么你就必須要調整你的正常習慣。因為Mate
不會為你的應用定義一個結構，它留給你來定義。從此以后，你將會不得不協調自己的團隊來確保你的所有開發人員以一個相容的方式編碼。最后，如果你碰巧需要
和 Adobe LiveCycle Data Services ES協作，那么請注意，Mate一般不會處理LiveCycle Data Sevices ES 提供的數據管理。
資源
PureMVC 框架
雖然Flex也可以使用PureMVC框架，但是它實際上并不是作為一個Flex框架而設計的。PureMVC的創建者希望PureMVC框架是與語言無關的。其實，如果你訪問他的網站，你會發現在多種語言上的實現以及代碼范例。
PureMVC 以模型—視圖—控制器模式（MVC
模式）為中心，以把項目切分到模型，視圖以及控制器層為目標。PureMVC中通過是Model，View以及Controller，這三個單件類體現了
這些層——而為了幫著這些層之間通訊使用了第四個單件類Façade ，同時他也作為中央存貯器的角色存在。
和Cairngorm很像，創建一個使用PureMVC框架的項目，需要分割你的項目到若干包中，然后通過繼承框架的類來顯現你的定制類。PureMVC 還加入了作為程序主入口點的Façade類。
優點
類似Cairngorm，PureMVC一個穩定的框架并且擁有一個龐大的活躍社區來支持它。因為它為應用需要如何被創建以及開發人員之間的標準化編碼提供了一個意義明確的結構，所以它也非常適合團隊開發。
缺點=
由于對單件的依賴，PureMVC
很容易就獲得與Cairngorm相同的批評。它并不是一個專門針對Flex的框架，所以它并不會像Cairngorm般利用MXML的特點。和
Cairngorm一樣，PureMVC對于事件處理擁有它自己的方法，并且它會使標準的Flex事件模型更難運作。PuremvC
是一個相當復雜的框架，相對更難快速學會。除非你的團隊非常熟悉它，培訓新的雇員會提高生產時間。
最后，還是和Cairngorm 一樣，PureMVC框架需要創建很多類，這些創建工作會增加生產時間和項目的大小。
資源
Swiz框架
Swiz
是一個為簡化事件處理與異步遠端方法呼叫提供方法的控制反轉（IoC）框架。Swiz框架主要的焦點放在以一種簡單有效的方式提供一個可靠的MVC規范。
和Cairngorm以及PureMVC所不同的是，它直接回避了宏大的Java模式并且不會強調任何預定義的文件夾結構。
使用Swiz創建一個項目需要告訴Swiz框架關于你的應用的組件。在Swiz的核心，Swiz是一個集中的工廠模式。組件都會經由一個成為BeanLoader的工具類載入到這個工廠。當應用開始的時候，工廠處理這些組件的實例化。
與此同時，Swiz 通過Autowire這個自定義Metatag來提供依賴管理。Autowire標簽是Swiz為你處理定義類之間依賴性的一個方法。
優點
Swiz是使用簡單并且不用為你的項目強制定義結構。憑借它的Autowire
依賴注入系統，和Mate一樣，既確保了組件之間的松耦合又為你管理了依賴性。同時，Swiz也和Mate一樣，使用了內建的Flex事件處理機制，這一
點在使用內部單件實現了全局事件分發之類的重要方面是非常有幫助的。
缺點
然后，又是和Mate一樣，Swiz并不為你的應用的結構定義許多，它留給你自己去做。所以，你將會不得不為你自己的團隊協調來確保你的所有開發人員以兼容的方式編碼。
第二，因為它使用了自定義的metatag，所以項目需要一些附加的設置——例如，設置一些額外的編譯參數。或者這些步驟不困難，但是其他框架不需要，而Swiz卻需要。文檔指明了Flex 2用戶，所以他在flex2之后的版本將不再是一個問題。
資源
做出你的選擇
雖然還不是很徹底，但是這里提供的信息配合資源，應該能夠為你對每個框架的方法，優點以及缺點提供了一個基本的了解。你會怎么從這些框架中選擇一個超過其他框架的框架呢？
也許第一個問題是，我是否需要一個框架？Flex 與MXML
為快速構建應用提供了非常強健的一套方法。我一般不使用框架的原因是當我嘗試適應框架的一套方法的時候需要做更多的工作，相比較僅僅使用Flex框架而
已。對我來說，一個框架需是一個能夠讓任務變得更簡單并且提高生產率的東西，而不是某些我用它只是因為我可以或者因為我想要讓自己成為一個更好的開發人員
而去使用。
就如本文開頭寫的，我在一個電話面試中所提到的，在給出為什么我沒有選擇使用一個框架的解釋之后，采訪者這樣反應,"我必須在一個巨大的團隊中工作。當然啦，你了解我需要多少有些了解框架的啦"。少許思考之后，我知道了他的意思。
使用框架的好處之一就是可以標準化一些事情如何被編碼。也就是說，如果程序員A 和程序員B使用相同的框架為同一項目的兩個部分工作，你可以很確定他們寫的是兼容的。所以可能你需要問你自己的另外一個問題就是，你想要強制確定多少結構？
框架非常大量的檢測了他們需要多少預定義的結構。如果你是工作在一個大型團隊中，你可能想要比做自己的項目更多強制的結構。預定義的結構提
供的團隊工作環境的簡化和代碼的一致性足夠彌補你為一個更需要結構的框架創建所有必須的類而增加生產時間和項目大小。相比之下，如果你是一個項目上工作的
唯一開發人員并且你只是需要一些東西來是生活更簡單速度更快的開發，然后可能就你需要一個那種不需要強調太多結構的框架來運用到你的項目上。
看起來， 選擇一個正確的框架或者選擇完全不使用框架，
只是開發人員的目標的一個功能呢個以及在哪個環境創建項目而已。我能給你的最好的建議就是誠實的高速你自己項目需要什么。我知道在我做完我的研究并且寫了
本文之后，我放開了對于框架的觀念，我認為它們的確實現了明確的需求。