文章目录
- 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