文章目錄
- MVC
- 消息通信,依賴注入
- MVCS
- 目錄結構
- Context
- Command
- View
- Models
- Services
- AwayBuilder架構
-
- awaybuilder-destop
- awaybuilder-core
- 參考
記一下自己對以前做的東西的了解。
AwayBuilder是一個遊戲場景編輯器。采用了robotlegs以依賴倒置原則寫的MVSC架構(這是我第一個接觸的架構)。
MVC
一開始隻有View
但是資料顯示,我們需要調用接口,擷取資料,存在視圖的某個屬性中,更新視圖。如果其他子產品想使用這個資料,需要知道這個視圖,或者重寫計算一遍。
把資料儲存到别處,和視圖不共享一個生命周期,分離出來的資料規定為(模型,提供資料隻是模型的一個功能,具體内容按需求來)。
現在分離了表現。但是控制加載資料這部分代碼,需要擷取資料,更新視圖。二種,放在視圖上,放在模型上。把這部分代碼剔除來,就是Controller(控制器)
分離出控制器後,就解耦了模型和視圖關于控制部分的聯系,模型和視圖它們隻關心控制器,不關心對方。
消息通信,依賴注入
視圖和模型對控制器的調用是一句話,但是還是要依賴于控制器(導入控制器的代碼)。同樣控制器隻關心視圖和模型對外的接口,不關心視圖和模型的環境。
為了能夠徹底分離和結構,通過調用代碼使用發送消息或其他動态形式,這樣就能做到獨立編譯(也友善測試)。
自動依賴注入是MVC架構的一個功能。
RobotLegs則是基于消息以及消息攜帶的資料等來實作解耦。
依賴注入和控制反轉其實就是同一個事情。
控制反轉是一個對象如何擷取他所依賴的對象的引用。
注入圖
MVCS
分離:MVCS 提供一種将你的應用程式分離到提供特定功能的無關聯的層的很自然的方法。 view 層處理使用者互動。 model 層處理使用者建立的或從外部擷取的資料。 controller 提供一種封裝各層之間複雜互動的機制。 最後, service 層提供一種和外界(比如遠端服務 API 或檔案系統)互動的獨立機制。
組織:通過這種分離我們自然獲得一個組織水準。 每個項目都需要某個組織水準。 是的,有人可以把他們所有的類都扔到頂級包下完事,但即使是最小的項目這也是不可接受的。 當一個項目有了一定的規模就需要開始組織類檔案的結構了。 當向同一個應用程式開發中增加團隊成員的時候問題就更加嚴重了。 RobotLegs 的 MVCS 實作為項目描繪出一個分為四層的優雅的組織結構。
解耦:Robotlegs 的MVCS實作将應用程式解耦為4層。 每層都與其它層隔離, 使分離類群組件分别測試變得非常容易。除了簡化測試程序, 通常也使類更具便攜性以在其它項目中使用。 比如, 一個連接配接到遠端 API 的 Service 類可能在多個項目中都很有用。 通過解耦這個類, 它可以不需重構便從一個項目轉移到另一個中使用。
Context:所謂Context(上下文),實際上是一套自展機制,用來初始化Robotlegs所使用的依賴注入以及各種核心工具。
Commands:所謂Commands(指令),代表的是應用程式所能執行的獨立操作。通常,Commands(指令)會作為對使用者操作的反應,但指令的作用并不僅限于此。
Mediators:所謂Mediators(中介),是用來管理應用程式中的視圖元件與應用程式中的其它對象之間的資訊交流。
Model:Models(模型)中儲存着資料資訊,并且表現出應用程式目前的狀态。
Service:Services(服務),是應用程式與外界的接口。
目錄結構
[domain.lib]
various utilities
[domain.project]
[projectmodule]
[model]
[events]
[vo]
ProjectModuleStateModel
[view]
[events]
[renderers]
[skins]
MyProjectModuleView
MyProjectModuleViewMediator
[controller]
[startup]
MyProjectModuleActionCommand
[service]
[helpers]
MyProjectModuleService
IProjectModuleService
[signals]
[projectmodule]
[model]
[events]
[vo]
ProjectModuleStateModel
[view]
[events]
[renderers]
[skins]
MyProjectModuleView
MyProjectModuleViewMediator
[controller]
[startup]
MyProjectModuleActionCommand
[service]
[helpers]
MyProjectModuleService
IProjectModuleService
[signals]
…
Context
Command
Controller 層由 Command 類展現(一個Command是一個簡明、單一目的的控制器controller對象)
初始化
View
View 由 Mediator 類展現。繼承 Mediator 的類管理應用程式中的 View Component 與應用程式中的其它對象之間的資訊交流。
建議通過 model 和 service 實作的接口将 model 和 service 注入 mediator。
Models
Model 有時被當做簡單的 Model 比如 UserModel,有時也被當做 Proxy 比如 UserProxy。
在一個 Model 裡監聽架構事件
雖然技術上可能,但強烈不建議這樣做。不要這樣做。隻是為了說清楚:不要這樣做。如果你這樣做了,不要說你沒被警告過.
被meditor注入,直接被調用。
那是command的責任!!!
Services
Service 用來通路應用程式範圍之外的資源。
Service 是進入外部資料的第一個點,是以它是操作一個外部服務傳回的資料的更好的選擇。
AwayBuilder架構
首先是
awaybuilder-destop:awaybuilder桌面應用
awaybuilder-core: awaybuilder core,用于界面和遊戲的聯系,事件處理。
away3d-core:3d遊戲引擎庫
依賴關系如下:
awaybuilder-destop依賴于awaybuilder-core
awaybuilder-core依賴于away3d-core
awaybuilder-destop
程式入口為:DesktopAppContext,
<desktop:DesktopAppContext contextView="{this}"/>
重寫Contex的startup事件。
映射command
override public function startup():void
{
super.startup();
this.commandMap.mapEvent(SceneReadyEvent.READY, SceneReadyCommand);
this.commandMap.mapEvent(DocumentRequestEvent.REQUEST_NEW_DOCUMENT, DocumentRequestCommand);
this.commandMap.mapEvent(DocumentRequestEvent.REQUEST_OPEN_DOCUMENT, DocumentRequestCommand);
this.commandMap.mapEvent(DocumentRequestEvent.REQUEST_IMPORT_DOCUMENT, DocumentRequestCommand);
this.commandMap.mapEvent(DocumentRequestEvent.REQUEST_CLOSE_DOCUMENT, DocumentRequestCommand);
//映射view到meditator
this.mediatorMap.mapView(AwaybuilderConfigSettingPopup, AwaybuilderConfigSettingPopupMediator);
/DI模式
this.injector.mapSingletonOf(IDocumentService, WooduanDesktopDocumentService);
awaybuilder-core
參考
https://www.cnblogs.com/skynet/archive/2012/03/21/2410042.html
https://github.com/robotlegs/robotlegs-documentation/blob/master/best-practices-zh-cn.textile#thecontext