本文和大家重點(diǎn)討論一下如何選擇一個(gè)Flex框架，這里向大家介紹了四種Flex框架的優(yōu)點(diǎn)和缺點(diǎn)，相信通過(guò)本文的簡(jiǎn)單描述你對(duì)Flex框架的選擇一定會(huì)自己的見(jiàn)解。

如何選擇一個(gè)Flex框架

翻譯自：http://www.adobe.com/devnet/flex/articles/flex_framework_02.html

Cairngorm

Cairngorm是一個(gè)廣為人知的老牌Flex框架。它是一個(gè)微型架構(gòu)——由一些設(shè)計(jì)模式組成用來(lái)降低團(tuán)隊(duì)協(xié)作的困難。
Cairngorm從Java的世界帶來(lái)了很多開(kāi)發(fā)理念，并且把重點(diǎn)放在三個(gè)關(guān)鍵區(qū)域：處理用戶動(dòng)作，封裝服務(wù)端的交互和業(yè)務(wù)邏輯，管理客戶端的狀態(tài)和界面呈現(xiàn)。
使用Cairngorm來(lái)構(gòu)建一個(gè)項(xiàng)目，需要將應(yīng)用代碼分離到不同的包并且繼承Cairngorm的類。以下是Cairngorm項(xiàng)目中一些主要的部分和類。

ModelLocator是一個(gè)儲(chǔ)存數(shù)據(jù)的單例，數(shù)據(jù)表示程序的狀態(tài)。單例類的性質(zhì)保證了程序中的所有組件取得的是相同的數(shù)據(jù)。
ServiceLocator是另一個(gè)單例，它集中管理所有服務(wù)如HTTPServices。同樣，由于是單例，程序中的所有組件取得的是相同的服務(wù)。
業(yè)務(wù)邏輯被封裝在command類中。command實(shí)現(xiàn)了命令模式，它們表示相應(yīng)用戶事件的邏輯。
事件被類FrontController處理，F(xiàn)rontController會(huì)把事件映射到相應(yīng)的Command。
Delegate類作為代理來(lái)對(duì)遠(yuǎn)端服務(wù)進(jìn)行請(qǐng)求和響應(yīng)。

優(yōu)點(diǎn)

Cairngorm在Flex社區(qū)廣為人知，作為Adobe開(kāi)源項(xiàng)目的一員，擁有活躍的社區(qū)和開(kāi)發(fā)者的支持。
其次，該框架吸取了Java開(kāi)發(fā)中許多寶貴的經(jīng)驗(yàn)，并成功得用于大型項(xiàng)目的開(kāi)發(fā)中。
并且，Cairngorm適用于團(tuán)隊(duì)開(kāi)發(fā)，因?yàn)樗峁┝私Y(jié)構(gòu)化的開(kāi)發(fā)方法來(lái)創(chuàng)建應(yīng)用，利于分布式的開(kāi)發(fā)。

缺點(diǎn)

需要寫(xiě)大量的類應(yīng)該是Cairngorm最多的負(fù)面評(píng)論了。在Cairngorm中，每一個(gè)event對(duì)應(yīng)一個(gè)command；因此，需要對(duì)程序觸發(fā)的每一個(gè)事件來(lái)寫(xiě)一個(gè)command類。而且，還要為command寫(xiě)一些其他的類，例如delegates。即使是一個(gè)中型的應(yīng)用也會(huì)導(dǎo)致大量的類產(chǎn)生。

其次,Cairngorm實(shí)現(xiàn)了自己的一套事件處理的方法。這增加了Flex內(nèi)置事件模型的復(fù)雜度，而且它還有限制。由于每個(gè)事件都有自己的的command，事件的響應(yīng)者被限制成1個(gè)。加之Cairngorm的事件不具冒泡特性，如果要發(fā)送數(shù)據(jù)到容器的其它層次則需要自己來(lái)實(shí)現(xiàn)。

第三個(gè)常見(jiàn)的批評(píng)是Cairngorm依賴全局的單例，這讓模塊和單元測(cè)試變得困難。盡管可以打破單例中的模型簡(jiǎn)化測(cè)試，但是會(huì)增加額外的過(guò)程。#p#

資源
Cairngormdeveloperdocumentation
DevelopingFlexRIAswithCairngormmicroarchitecture–Part1:IntroducingCairngorm(StevenWebsterandLeonTanner,August2008)
ExampleCairngormproject

Mate

Mate是一個(gè)基于標(biāo)簽的，事件驅(qū)動(dòng)的框架?；跇?biāo)簽意味著它可以完全實(shí)現(xiàn)在MXML中。該框架的目的是讓事件響應(yīng)者的聲明變得簡(jiǎn)便。
在項(xiàng)目中使用Mate只需要處理兩個(gè)方面：使用1個(gè)或者多個(gè)事件，有一個(gè)成為”eventmap“的MXML文件——被包含在主程序中的一個(gè)MXML文件。它定義了需要監(jiān)聽(tīng)的事件以及如何被處理。必須有1個(gè)eventmap，而且允許有多個(gè)。

Mate也實(shí)現(xiàn)了依賴注入（Dependencyinjection）的理念——有時(shí)被稱為好萊塢原則,或“don’tcallus,we’llcallyou”。對(duì)象的創(chuàng)建時(shí)這樣一種方式：數(shù)據(jù)被創(chuàng)建并且注入到對(duì)象中。也就是說(shuō)，對(duì)象不會(huì)喊著要數(shù)據(jù)（”don’tcallus”），而是數(shù)據(jù)被傳送給對(duì)象（”we’llcallyou”）。

優(yōu)點(diǎn)

Mate使用依賴注入提升了松耦合性。因?yàn)榻M件不依賴全局的單例，能更自由地作為對(duì)立的部分。Mate不會(huì)阻止你使用Flex內(nèi)建的事件機(jī)制，也不會(huì)像Cairngorm一樣為每個(gè)事件都使用單獨(dú)的響應(yīng)。Mate的MXML標(biāo)簽文件簡(jiǎn)單易用，而且文檔優(yōu)秀，在官網(wǎng)上有大量的代碼實(shí)例。

缺點(diǎn)

Mate使用MXML文件構(gòu)建，要是作為一個(gè)ActionScript開(kāi)發(fā)者，就需要調(diào)整自己的習(xí)慣。而且Mate沒(méi)有為應(yīng)用程序制定結(jié)構(gòu)，這份工作留給了開(kāi)發(fā)者。
因此，需要加強(qiáng)團(tuán)隊(duì)協(xié)作來(lái)保證代碼的兼容性。還有一個(gè)問(wèn)題與AdobeLiveCycleDataServicesES有關(guān)，要知道Mate暫時(shí)還不能處理LiveCycleDataServices提供的數(shù)據(jù)管理方面的功能。#p#

資源
Matedocumentation
Exampleprojects
PodcastinterviewwithMateframeworkcreatorLauraArguello
 

PureMVC

盡管PureMVC用在Flex上，但是它并不是只為Flex設(shè)計(jì)的。PureMVC的創(chuàng)建者想讓它是一個(gè)語(yǔ)言無(wú)關(guān)的框架。如果你訪問(wèn)它的網(wǎng)站，會(huì)發(fā)現(xiàn)大量的不同語(yǔ)言的實(shí)現(xiàn)版本。

PureMVC以MVC模式為中心，其目標(biāo)是把項(xiàng)目分離成模型層，視圖層和控制層。這三個(gè)層表現(xiàn)為三個(gè)單例——Model，View和Controller，還有第四個(gè)單例Facade用來(lái)對(duì)前三個(gè)單例進(jìn)行集中管理，是Facade模式的實(shí)現(xiàn)。

與Cairngorm很像，使用PureMVC創(chuàng)建一個(gè)項(xiàng)目需要把項(xiàng)目分成多個(gè)包，然后繼承框架中的類來(lái)構(gòu)造自己的類。***還要為項(xiàng)目額外創(chuàng)建一個(gè)Facade類來(lái)作為程序的入口。

優(yōu)點(diǎn)

與Cairngorm一樣，PureMVC是一個(gè)結(jié)構(gòu)良好的框架，有活躍的社區(qū)和開(kāi)發(fā)者支持。它很適合團(tuán)隊(duì)開(kāi)發(fā)，其清晰的結(jié)構(gòu)能告訴開(kāi)發(fā)者如何創(chuàng)建和組織代碼。

缺點(diǎn)

因?yàn)樗蕾囉趩卫?，所以有著和Cairngorm一樣的缺點(diǎn)。它不是一個(gè)特定的Flex框架，所以沒(méi)有充分利用到MXML的特性。

跟Cairngorm類似，PureMVC有自己的事件處理方式，但是跟標(biāo)準(zhǔn)的Flex事件模型一起工作會(huì)增加開(kāi)發(fā)難度。

PureMVC是一個(gè)比較復(fù)雜的框架，有相當(dāng)陡的學(xué)習(xí)曲線。除非你的團(tuán)隊(duì)很熟悉它，否則培訓(xùn)會(huì)占用很多時(shí)間。

還有，PureMVC也需要?jiǎng)?chuàng)建很多類，既增加了產(chǎn)品的開(kāi)發(fā)時(shí)間，又增大了項(xiàng)目的尺寸。#p#

資源
Documentationandlicensing
Exampleproject
PodcastinterviewwithPureMVCframeworkcreatorCliffHall

Swiz

Swiz是一個(gè)控制反轉(zhuǎn)（IoC,InversionofControl）Flex框架，它提供一些機(jī)制來(lái)簡(jiǎn)化事件處理和異步遠(yuǎn)程調(diào)用。Swiz的真正意圖是以一種簡(jiǎn)單高效的方式提供一個(gè)MVC范式。與Cairngorm和PureMVC不同，它借鑒了Java的一些模式，摒棄了預(yù)定義的文件結(jié)構(gòu)。

使用Swiz創(chuàng)建一個(gè)項(xiàng)目需要告訴Swiz所用到的組件。以這個(gè)為核心，Swiz是一個(gè)集中管理的工廠模式。組件被名為BeanLoader的靜態(tài)類加載到工廠當(dāng)中，由工廠來(lái)處理組建的實(shí)例化。
Swiz還提供依賴管理，它使用了一個(gè)名為Autowire的自定義標(biāo)簽，Autowire標(biāo)簽定義依賴然后交給Swiz處理。

優(yōu)點(diǎn)

Swiz簡(jiǎn)單易用，沒(méi)有預(yù)定義的文件結(jié)構(gòu)。類似于Mate，Swiz通過(guò)Autowire這個(gè)依賴注入系統(tǒng)，提升了松耦合性。也類似于Mate，它使用Flex內(nèi)建的事件模型，并且使用單例來(lái)發(fā)送一個(gè)關(guān)鍵的事件。

缺點(diǎn)

跟Mate一樣，Swiz沒(méi)有為項(xiàng)目的結(jié)構(gòu)做過(guò)多的定義，這些留給了開(kāi)發(fā)者，因此，需要加強(qiáng)團(tuán)隊(duì)協(xié)作來(lái)保證代碼的兼容性。
其次，它使用了自定義標(biāo)簽，項(xiàng)目的建立會(huì)額外多出一些步驟，例如設(shè)置額外的編譯選項(xiàng)。這些過(guò)程并不復(fù)雜，但是至少這些過(guò)程在其他框架中不需要。文檔強(qiáng)調(diào)的是Flex2的開(kāi)發(fā)者，所以可能不適合比Flex2更新的版本。

資源

Documentationandexamples
PodcastinterviewwithSwizframeworkcreatorChrisScott

做出選擇

雖然描述的并不詳盡，但是這些信息加上資源足以讓人理解提到的每個(gè)框架的方法論，優(yōu)點(diǎn)，還有缺點(diǎn)。看了這些，你將如何作出取舍呢？
也許***個(gè)問(wèn)題應(yīng)該問(wèn)：我是否需要一個(gè)框架？Flex和MXML為快速應(yīng)用開(kāi)發(fā)提供了健全的系統(tǒng)和方法。我一直以來(lái)不太使用框架的原因是，相對(duì)于使用Flex框架而言，使用額外的框架會(huì)讓我為了適應(yīng)這些框架而去做更多的事情。我認(rèn)為，框架的作用是簡(jiǎn)化工作任務(wù)和提高生產(chǎn)率，而不是為了證明我能用或者用了就說(shuō)明我是一個(gè)優(yōu)秀的開(kāi)發(fā)者。

在一個(gè)電話面試中，我解釋了自己為什么選擇不使用框架，面試者回應(yīng)：”我們是一個(gè)大的團(tuán)隊(duì)，所以你明白為什么我們需要一些框架了”。一番思索之后，我確實(shí)明白了它的意思。
使用框架的一個(gè)好處就是它讓代碼的編寫(xiě)標(biāo)準(zhǔn)化了。一個(gè)程序員A和一個(gè)程序員B使用同一個(gè)框架負(fù)責(zé)同一個(gè)項(xiàng)目的兩個(gè)不同部分，那么可以認(rèn)為他們寫(xiě)的程序是兼容的。也許這時(shí)候應(yīng)該考慮另一個(gè)問(wèn)題：有多少結(jié)構(gòu)允許被強(qiáng)加？

這里介紹的這些框架或多會(huì)少都包含了一些預(yù)定義的結(jié)構(gòu)。與獨(dú)自開(kāi)發(fā)相比，團(tuán)隊(duì)開(kāi)發(fā)需要更多這樣的結(jié)構(gòu)。這些結(jié)構(gòu)可以增加項(xiàng)目的開(kāi)發(fā)時(shí)間和文件尺寸，但是也會(huì)提升團(tuán)隊(duì)的開(kāi)發(fā)環(huán)境和代碼的一致性。相比這下，如果你是項(xiàng)目唯一的開(kāi)發(fā)者，就不需要把事情搞那么復(fù)雜，或許你需要一個(gè)沒(méi)有這么多預(yù)定義結(jié)構(gòu)的框架。
所以，選擇一個(gè)正確的框架或者壓根不用框架是由開(kāi)發(fā)環(huán)境和項(xiàng)目決定的。我能給出的***的建議是了解你的項(xiàng)目。通過(guò)我的調(diào)查和這篇文章，我認(rèn)為自己對(duì)框架的看法會(huì)更深刻，它們確實(shí)可以滿足一些需求。

【編輯推薦】

1. 開(kāi)源Flex框架集錦
2. Flex基礎(chǔ) 創(chuàng)建***個(gè)Flex項(xiàng)目
3. 常見(jiàn)十大Flex調(diào)試工具和Flex框架 
4. FlexBuilder3.0與Eclipse3.4的***結(jié)合
5. 學(xué)習(xí)筆記 FlexBuilder2.0中如何使用基于Lists的控件