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