Flex框架選擇指南
本文和大家重點討論一下Flex框架中PureMVC和Swiz的優(yōu)缺點，從而學(xué)習(xí)如何選擇一個Flex框架，盡管PureMVC用在Flex上，但是它并不是只為Flex設(shè)計的，而Swiz是一個控制反轉(zhuǎn)（IoC,InversionofControl）框架，它提供一些機制來簡化事件處理和異步遠程調(diào)用。
如何選擇一個Flex框架
PureMVC
盡管PureMVC用在Flex上，但是它并不是只為Flex設(shè)計的。PureMVC的創(chuàng)建者想讓它是一個語言無關(guān)的框架。如果你訪問它的網(wǎng)站，會發(fā)現(xiàn)大量的不同語言的實現(xiàn)版本。
PureMVC以MVC模式為中心，其目標是把項目分離成模型層，視圖層和控制層。這三個層表現(xiàn)為三個單例——Model，View和Controller，還有第四個單例Facade用來對前三個單例進行集中管理，是Facade模式的實現(xiàn)。
與Cairngorm很像，使用PureMVC創(chuàng)建一個項目需要把項目分成多個包，然后繼承框架中的類來構(gòu)造自己的類。最后還要為項目額外創(chuàng)建一個Facade類來作為程序的入口。
優(yōu)點
與Cairngorm一樣，PureMVC是一個結(jié)構(gòu)良好的框架，有活躍的社區(qū)和開發(fā)者支持。它很適合團隊開發(fā)，其清晰的結(jié)構(gòu)能告訴開發(fā)者如何創(chuàng)建和組織代碼。
缺點
因為它依賴于單例，所以有著和Cairngorm一樣的缺點。它不是一個特定的Flex框架，所以沒有充分利用到MXML的特性。
跟Cairngorm類似，PureMVC有自己的事件處理方式，但是跟標準的Flex事件模型一起工作會增加開發(fā)難度。
PureMVC是一個比較復(fù)雜的Flex框架，有相當陡的學(xué)習(xí)曲線。除非你的團隊很熟悉它，否則培訓(xùn)會占用很多時間。
還有，PureMVC也需要創(chuàng)建很多類，既增加了產(chǎn)品的開發(fā)時間，又增大了項目的尺寸。
資源
Documentationandlicensing
Exampleproject
PodcastinterviewwithPureMVCframeworkcreatorCliffHall
Swiz
Swiz是一個控制反轉(zhuǎn)（IoC,InversionofControl）Flex框架，它提供一些機制來簡化事件處理和異步遠程調(diào)用。Swiz的真正意圖是以一種簡單高效的方式提供一個MVC范式。與Cairngorm和PureMVC不同，它借鑒了Java的一些模式，摒棄了預(yù)定義的文件結(jié)構(gòu)。
使用Swiz創(chuàng)建一個項目需要告訴Swiz所用到的組件。以這個為核心，Swiz是一個集中管理的工廠模式。組件被名為BeanLoader的靜態(tài)類加載到工廠當中，由工廠來處理組建的實例化。
Swiz還提供依賴管理，它使用了一個名為Autowire的自定義標簽，Autowire標簽定義依賴然后交給Swiz處理。
優(yōu)點
Swiz簡單易用，沒有預(yù)定義的文件結(jié)構(gòu)。類似于Mate，Swiz通過Autowire這個依賴注入系統(tǒng)，提升了松耦合性。也類似于Mate，它使用Flex內(nèi)建的事件模型，并且使用單例來發(fā)送一個關(guān)鍵的事件。
缺點
跟Mate一樣，Swiz沒有為項目的結(jié)構(gòu)做過多的定義，這些留給了開發(fā)者，因此，需要加強團隊協(xié)作來保證代碼的兼容性。
其次，它使用了自定義標簽，項目的建立會額外多出一些步驟，例如設(shè)置額外的編譯選項。這些過程并不復(fù)雜，但是至少這些過程在其他框架中不需要。文檔強調(diào)的是Flex2的開發(fā)者，所以可能不適合比Flex2更新的版本。
資源
Documentationandexamples
PodcastinterviewwithSwizframeworkcreatorChrisScott
做出選擇
雖然描述的并不詳盡，但是這些信息加上資源足以讓人理解提到的每個框架的方法論，優(yōu)點，還有缺點。看了這些，你將如何作出取舍呢？
也許第一個問題應(yīng)該問：我是否需要一個框架？Flex和MXML為快速應(yīng)用開發(fā)提供了健全的系統(tǒng)和方法。我一直以來不太使用框架的原因是，相對于使用Flex框架而言，使用額外的框架會讓我為了適應(yīng)這些框架而去做更多的事情。我認為，框架的作用是簡化工作任務(wù)和提高生產(chǎn)率，而不是為了證明我能用或者用了就說明我是一個優(yōu)秀的開發(fā)者。
在一個電話面試中，我解釋了自己為什么選擇不使用框架，面試者回應(yīng)：”我們是一個大的團隊，所以你明白為什么我們需要一些框架了”。一番思索之后，我確實明白了它的意思。
使用框架的一個好處就是它讓代碼的編寫標準化了。一個程序員A和一個程序員B使用同一個框架負責(zé)同一個項目的兩個不同部分，那么可以認為他們寫的程序是兼容的。也許這時候應(yīng)該考慮另一個問題：有多少結(jié)構(gòu)允許被強加？
這里介紹的這些框架或多會少都包含了一些預(yù)定義的結(jié)構(gòu)。與獨自開發(fā)相比，團隊開發(fā)需要更多這樣的結(jié)構(gòu)。這些結(jié)構(gòu)可以增加項目的開發(fā)時間和文件尺寸，但是也會提升團隊的開發(fā)環(huán)境和代碼的一致性。相比這下，如果你是項目唯一的開發(fā)者，就不需要把事情搞那么復(fù)雜，或許你需要一個沒有這么多預(yù)定義結(jié)構(gòu)的框架。
所以，選擇一個正確的框架或者壓根不用框架是由開發(fā)環(huán)境和項目決定的。我能給出的最好的建議是了解你的項目。通過我的調(diào)查和這篇文章，我認為自己對框架的看法會更深刻，它們確實可以滿足一些需求。
翻譯自：http://www.adobe.com/devnet/flex/articles/flex_framework_02.html
【編輯推薦】
