Actionscript 3(簡稱as)自2006年誕生以來，出現了一大批很優秀框架。就我的知識領域，運用包括pureMVC、pushButton
Engine(組件框架)、Robotlegs、Ash等等。我將對這幾個通用的開發框架進行一個較深入的總結。同時下文的種種判斷、結論可能不完全正確，完全限於個人的思考、理解得到的。運用框架讓開發效率更高，擴展性好，可維護。理解框架讓框架的作用發揮極致，開發揮灑自如！
1 PureMVC
PureMVC很多人應該很熟悉，記得那時候as的開發框架還是很少的，這種基於mvc的框架對於as來說很實用的，as是客戶端語言，處理大量視圖邏輯，提供了機制去解決視圖和控制器間的低耦合。既然是開發框架，我從幾個方面去分析它。
> 框架機制：PureMVC幾個核心的類組成：Facade(外觀)，Proxy(模型代理)，Mediator(中介器)，Command(控制器)。Facade是整個框架的核心，包括mediator、command、proxy全部由它管理。框架大量採用單例，包括Facade本身。mediator是視圖的代理器，負責和view打交道，view本身只提供一個ui佈局，邏輯控制處理全部在mediator中完成。command提供一種命令模式，單獨處理一項邏輯事務，並且這種對應是可以配置，即使用一個命令名稱對應一個命令體。這樣將整個控制邏輯簡單化，單一化模塊化，便於替換，更新維護。proxy是數據模型的代理，一般情況我們會設計vo，就是特定的數據模型結構(data struct)，然後使用proxy進行代理。整個框架靜態分析下來就是這樣的了，至此我們還沒有分析框架的事件流，沒有這個無法進行邏輯控制，協作處理。PureMVC採用了另一種設計模式，觀察者模式，這裏就涉及到觀察者、通知者、消息。觀察者就是對象的一個消息處理方法，通知者自然就是發送消息，消息又包括消息名稱、內容等。消息發送是通過Facade進行的。Facade提供了機制，在mediator、commnad被註冊時進行了消息名稱+處理句柄的關聯。所以當通過Facade發送消息的時候，將查找這種關聯，並讓那些observer觀察者(meditor、command)進行響應。
> 有圖有真相，看看框架示意圖更加清晰點
> 運用與優缺分析
第一步，繼承Facade，實現自己的外觀，進行數據模型代理、控制器、中介器的安裝。設計數據模型(vo)，完成對數據模型vo的proxy。安裝視圖組織設計對應的mediator，完成視圖事件處理句柄和控制邏輯。劃分邏輯，將不同的處理邏輯封裝在不同的command中。
pureMVC優點體現在：輕量級的庫、簡單易用、極大降低耦合度，獨立不依賴第三方庫。可以很好的協調人員進行mvc模式開發。就當前的框架而言，由於Facade是單例的，在多模塊協作會出現問題。一個解決方案是讓Facade在不同的包下。當然pureMVC提供了多核版本，這裏就不進行討論了。
2 PushButton Engine(組件框架)
pushButton其實是一個遊戲engine，這裏我列出來，是因爲pushButton裏面使用了一種基於組件的開發模式。按着設計者的初衷，一個遊戲的設計，拋棄複雜的繼承(因爲繼承本身也有諸多弊端，在複雜的遊戲世界裏)，而採用一種“平鋪”的方式，整個系統採用實體+組件完成。這個engine是比較複雜的，至今我的理解也不深入。如果是詳細的討論整個engine的開發流程，必須單獨寫一篇了。
> 框架機制：一切皆組件。pushButton包括幾個核心類：entity(實體)、component(組件)、template(模板)、group(組)。entity就是一個對象，比如角色、npc，是個抽象的對象。entity總是由component組成，各個component負責不同部分，比如有的是渲染，空間屬性，數據模型等。template理解爲可以多次初始化創建的entity。group是一組對象的集合，當group被創建的時候，group的子節點objectReference對應的實體等也會被初始化創建。pushButton提供了查找、訪問別的組件的接口，同時提供了一個共享的eventDispatcher，實現消息事件的傳遞。如果深入去研究，有LevelManager(負責關卡的具體初始化工作)、NameManager(負責名稱和類對象索引)、TemplateManager(負責加載卸載關卡文件，和序列化控制)等。
> 框架示意圖
查看大圖: Go，右鍵另存爲即可。
> 運用與優缺分析
pushButton engine提供了基於XML配置文件的方法加載讀取遊戲，特別是關卡類遊戲。一切基於組件！ 在設計的時候，劃分好不同的entity，然後分別設計不同的component。如果使用配置，必須寫明objectReference，以完成初始化工作。如果使用手動，需要手動給entity添加不同的component，並手動實現整個流程。pushButton提供了屏幕管理類，方便視圖間的切換，繼承BaseScreen，實現自定義的screen。pushButton api很豐富，提供了很多公用組件模塊。對應大的項目可以考慮發佈一下組件，讓多人提供協作開發。
pushButton的api相對比較複雜，engine核心控制邏輯也需要深入學習才能弄懂！對應這樣一個engine，學習成本相對是較高的，穩定性方面也可能存在風險。
3 Robotlegs
robotlegs框架對我而言，很熟悉了。我們的整個項目ui部分完全是基於這個開發的，我還看到過有人使用robotlegs開發出了完整的大型rpg遊戲。robotlegs本質上還是mvc類型框架。不過robotlegs使用了依賴注入的方式降低對象間的耦合，簡單的說對象間的相互引用是通過robotlegs框架完成的，同時robotlegs提供了更好的通信機制，和更低的耦合性。
> 框架機制：robotlegs本質上也是使用mvc框架機制。包括：Actor(數據模型)、mediator(中介器)、command(控制器)、context(上下文)。整個框架的核心是依賴注入。context中負責完成幾個映射的初始化工作，包括控制器、中介器、視圖的映射。同時還包括對注入器的初始化工作。並且context裏面還提供了一個事件派發器eventDispatcher。actor就是model部分，對應自定義數據模型一般繼承actor，事件數據模型更新是派發事件通知給meditor和command。mediator提供對view的中介，負責處理和view的交互，發生消息命令。mediator被注入了meditorMap，可以實現新的視圖中介器關聯。command即是控制器部分，負責處理特定的邏輯塊。需要說明的是command被注入了commandMap、meditorMap、eventDispatcher，還有injector。這些對象提供了command更加廣闊的能力，包括髮送事件、映射新的命令關聯、新的視圖中介器關聯。最後就是mvcs中的“s”，s即是service，提供獲取外部數據的服務功能。本質上將robotlegs、pureMVC是一個東西，最大的區別是依賴注入、事件派發機制。
> 框架示意圖
事件流參看Robotlegs官網: Go
> 運用與優缺分析
robotlegs的具體運用和pureMVC很像。繼承context設計自己的context，完成數據模型、視圖、命令體映射等工作。設計基於actor的數據模型，當模型屬性改變時派發事件。完成視圖組織對應的mediator，安裝好視圖事件處理句柄，和處理邏輯。設計完成特定處理的命令體。注意的是依賴注入是框架自己完成的，並且注入點可以使用接口。
robotlegs的優勢可見一斑：輕量級的庫、簡單易用、極大降低耦合度。耦合度比pureMVC做的更徹底。並且依賴注入是可配置的。同時，我認爲robotlegs的事件機制更高效，簡單易懂，整個框架通過eventDispatcher對象進行收發。對於劣勢可能是在於使用成本方面，由於引用依賴注入，框架要複雜很多。同時對於不需要開發大量視圖交互的遊戲，就沒有這個優勢了。
4 Ash
Ash是richardlord在2012設計的框架，藉助這個框架richardlord開發了一個太空大戰遊戲，讓我看到一個新的設計框架的誕生。實體系統現在正變得越來越受歡迎，有名的例子比如Unity。當然Ash現在很簡陋，還不成熟，相信richardlord能做的更好！
> 框架機制：“實體系統結構來源於解決遊戲主循環這個問題的一次嘗試。它將遊戲主循環作爲整個遊戲的核心，並且預先假設在現代遊戲結構中，簡化遊戲主循環比其他任何方面都重要，比如，它比分離控制器上的視角重要的多”。這是這個框架的出發點，簡化遊戲主循環。在ash中，最終遊戲的主循環控制完全通過迭代system的update方法實現。ash包括幾個核心類：entity(實體)、component(組件)、node(節點)、system(系統)。entity對應任何遊戲都是存在的，可以理解爲遊戲中一個用例，一個組成對象，比如太空飛船。component理解爲entity的不同部分，飛船可以分爲渲染、數據模型、碰撞檢測、控制組件等。system可以理解爲處理具體一組抽象的針對node節點的邏輯。node是爲system服務的，因爲一般來說系統不關注具體的entity，而是關注一組特定的節點。節點又是由特定的組件構成的。本質上講node提供了特定或者抽象的entity的組件的訪問。system通過處理特定的node，實現處理對應的entity的組件，而組件對應一個entity來說，是共享傳遞的，從而實現邏輯處理。
> 框架示意圖
> 運用與優缺分析
Ash提供了Game類，使用時考慮給Game添加處理系統即可。一般會先劃分不同entity，以及添加各自對應的component類。處理邏輯有先後順序，決定了添加system到Game時有順序安排，通過劃分邏輯處理層次，將設計不同的system的擴展類，同時設計出配合system處理的node類。node類本質上是收集對entity的component的訪問。整個遊戲結構一目瞭然！
Ash關注解決遊戲主循環，在處理共性抽象方面很有特色。採用設計不同的組件來表達entity，顯得十分清晰。不同system的設計針對處理不同邏輯。整個系統看起來簡單有效。缺點是不合適開發大量視圖交互的遊戲，比如sns類webgame。同時如何良好劃分不同的系統，設計不同的支持node，也是個難點。
Conclusion
自然as是博大精深的，還有很多其他優秀的框架，有的框架是爲特定的遊戲類型書寫的，比喻很棒的位圖Engine Flixel，這裏沒法一一列舉和討論。可以肯定的是開發框架爲軟件系統的設計提供了一套機制，劃分出更加合理的模塊類結構，低耦合，更簡單方便的對象間交互協作等，讓開發變的簡單快速，並且維護性好，便於二次開發。接下來，我將應用這些框架，設計更多的應用、遊戲出來。趕緊試試吧，接納向新思想，你一定會更加進步！
參考：
http://www.ibm.com/developerworks/cn/java/j-lo-puremvc/index.html
http://bbs.blueidea.com/thread-2969839-1-1.html
http://bbs.9ria.com/thread-140584-1-1.html
http://www.adobe.com/cn/devnet/actionscript/articles/intro-robotlegs-pt1.html
http://www.fans8.com/?p=646