如何選擇一個Flex框架

本文和大家重點討論一下如何選擇一個Flex框架，這裡向大家介紹了四種Flex框架的優點和缺點，相信通過本文的簡單描述你對Flex框架的選擇一定會自己的見解。

如何選擇一個Flex框架

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依賴全域性的單例，這讓模組和單元測試變得困難。儘管可以打破單例中的模型簡化測試，但是會增加額外的過程。

Mate

Mate是一個基於標籤的，事件驅動的框架。基於標籤意味著它可以完全實現在MXML中。該框架的目的是讓事件響應者的宣告變得簡便。
在專案中使用Mate只需要處理兩個方面：使用1個或者多個事件，有一個成為”eventmap“的MXML檔案——被包含在主程式中的一個MXML檔案。它定義了需要監聽的事件以及如何被處理。必須有1個eventmap，而且允許有多個。

Mate也實現了依賴注入（Dependencyinjection）的理念——有時被稱為好萊塢原則,或“don’tcallus,we’llcallyou”。物件的建立時這樣一種方式：資料被建立並且注入到物件中。也就是說，物件不會喊著要資料（”don’tcallus”），而是資料被傳送給物件（”we’llcallyou”）。

優點

Mate使用依賴注入提升了鬆耦合性。因為元件不依賴全域性的單例，能更自由地作為對立的部分。Mate不會阻止你使用Flex內建的事件機制，也不會像Cairngorm一樣為每個事件都使用單獨的響應。Mate的MXML標籤檔案簡單易用，而且文件優秀，在官網上有大量的程式碼例項。

缺點

Mate使用MXML檔案構建，要是作為一個ActionScript開發者，就需要調整自己的習慣。而且Mate沒有為應用程式制定結構，這份工作留給了開發者。
因此，需要加強團隊協作來保證程式碼的相容性。還有一個問題與AdobeLiveCycleDataServicesES有關，要知道Mate暫時還不能處理LiveCycleDataServices提供的資料管理方面的功能。

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也需要建立很多類，既增加了產品的開發時間，又增大了專案的尺寸。

Swiz

Swiz是一個控制反轉（IoC,InversionofControl）Flex框架，它提供一些機制來簡化事件處理和非同步遠端呼叫。Swiz的真正意圖是以一種簡單高效的方式提供一個MVC正規化。與Cairngorm和PureMVC不同，它借鑑了Java的一些模式，摒棄了預定義的檔案結構。

使用Swiz建立一個專案需要告訴Swiz所用到的元件。以這個為核心，Swiz是一個集中管理的工廠模式。元件被名為BeanLoader的靜態類載入到工廠當中，由工廠來處理組建的例項化。
Swiz還提供依賴管理，它使用了一個名為Autowire的自定義標籤，Autowire標籤定義依賴然後交給Swiz處理。

優點

Swiz簡單易用，沒有預定義的檔案結構。類似於Mate，Swiz通過Autowire這個依賴注入系統，提升了鬆耦合性。也類似於Mate，它使用Flex內建的事件模型，並且使用單例來傳送一個關鍵的事件。

缺點

跟Mate一樣，Swiz沒有為專案的結構做過多的定義，這些留給了開發者，因此，需要加強團隊協作來保證程式碼的相容性。
其次，它使用了自定義標籤，專案的建立會額外多出一些步驟，例如設定額外的編譯選項。這些過程並不複雜，但是至少這些過程在其他框架中不需要。文件強調的是Flex2的開發者，所以可能不適合比Flex2更新的版本。

做出選擇

雖然描述的並不詳盡，但是這些資訊加上資源足以讓人理解提到的每個框架的方法論，優點，還有缺點。看了這些，你將如何作出取捨呢？
也許第一個問題應該問：我是否需要一個框架？Flex和MXML為快速應用開發提供了健全的系統和方法。我一直以來不太使用框架的原因是，相對於使用Flex框架而言，使用額外的框架會讓我為了適應這些框架而去做更多的事情。我認為，框架的作用是簡化工作任務和提高生產率，而不是為了證明我能用或者用了就說明我是一個優秀的開發者。

在一個電話面試中，我解釋了自己為什麼選擇不使用框架，面試者回應：”我們是一個大的團隊，所以你明白為什麼我們需要一些框架了”。一番思索之後，我確實明白了它的意思。
使用框架的一個好處就是它讓程式碼的編寫標準化了。一個程式設計師A和一個程式設計師B使用同一個框架負責同一個專案的兩個不同部分，那麼可以認為他們寫的程式是相容的。也許這時候應該考慮另一個問題：有多少結構允許被強加？

這裡介紹的這些框架或多會少都包含了一些預定義的結構。與獨自開發相比，團隊開發需要更多這樣的結構。這些結構可以增加專案的開發時間和檔案尺寸，但是也會提升團隊的開發環境和程式碼的一致性。相比這下，如果你是專案唯一的開發者，就不需要把事情搞那麼複雜，或許你需要一個沒有這麼多預定義結構的框架。
所以，選擇一個正確的框架或者壓根不用框架是由開發環境和專案決定的。我能給出的最好的建議是瞭解你的專案。通過我的調查和這篇文章，我認為自己對框架的看法會更深刻，它們確實可以滿足一些需求。

來源:9ria 翻譯自：http://www.adobe.com/devnet/flex/articles/flex_framework.html