AS3框架Robotlegs介绍，第一部分：Context和Mediators

最新推荐文章于 2024-08-28 09:55:10 发布

spring19840513

最新推荐文章于 2024-08-28 09:55:10 发布

阅读量1.6k

点赞数

分类专栏： Flex架构 Flex/AS 文章标签：框架 library application actionscript function 工作

Flex/AS 同时被 2 个专栏收录

39 篇文章

订阅专栏

Flex架构

2 篇文章

订阅专栏

本文介绍了RobotlegsAS3框架的使用，它提供了一种机制，用于应用程序中的对象之间进行通信，简化了通信任务，减少了重复代码，并管理依赖注入。文章通过一个简单的“HelloWorld”示例，概述了Robotlegs的基本结构和Context、Mediators等关键概念，激发读者对框架进一步探索的兴趣。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

目前在进行Actionscript 3 开发时，有多种框架可供我们选择，很显然，这是一个不错的迹象。相关的开源社区也比较活跃，出现了一些使开发变得更加容易的工具。在过去的一年中，Robotlegs AS3框架的使用有了快速的增长，其使用者包括主要的媒体公司、独立的游戏开发者、创业公司，以及各种规模的企业应用。

本文是发表在InsideRIA上Robotlegs 系列文章的第一部分。在接下来的几个星期里，本系列的其它文章将详细介绍Robotlegs 的基础概念以及一些高级概念（涉及到如何使用第三方实用程序、库）。

Roboglegs是什么？

简单地说，Robotlegs 提供了一种机制，用于应用程序中的对象之间进行通信。比如对象A需要和对象B进行通信，在Robotlegs 的帮助下对象A甚至不需要知道对象B是否存在。那么它们如何进行通信呢？最简单的答案是通过事件，在Flash中，原生的事件系统为这种通信方式带来了很多便利，你不可避免地每天都要使用事件。位于显示列表上的对象通过事件进行通信，事件冒泡允许对象从其它显示对象接收消息，但是如果对象并不位于显示对象列表上，该如何进行通信呢？这正是像Robotlegs 这样的框架能为你提供帮助的地方。

就其核心来讲，Robotlegs 是一系列功能模块和接口的集合。在应用程序中，这些功能模块和接口用于简化通信任务，减少重复代码，并且管理依赖注入。除此以外，Robotlegs 提供了一个轻量级的MVC+S（Model、View、Controller和Service）实现，作为应用开发的起点。如果你有使用PureMVC框架的经验，你将很快熟悉如何在Robotlegs 中使用Mediators 和Commands；如果没有，也不必担心，我们将马上深入的介绍这些类。

本文将通过一个简单的“Hello World”，对Robotlegs 进行概述。看完这个例子后，你可能会想，“嗯，我能毫无困难地在单个M XML 文件中完成这一切。”但这只是一个很简单的例子，切记，在大型项目中是不能这么做的。这里并不打算对Robotlegs 进行详细的解剖，但是希望它足以激发你的兴趣。在文末我已经提供了一些资源方便你对Robotlegs 进行进一步探索。下面，还是让我们来看一些代码。

Robotlegs MVC+S应用的基本结构
一个典型的Robotlegs MVC+S应用由以下几部分构成：
 Context  Context负责初始化依赖注入以及各种Robotlegs 需要使用的核心功能。
 Mediators  Mediators负责应用中视图组件与应用中其它对象之间的通信。
 Commands  Commands代表应用所能执行的单个行为。Commands的典型功能是响应用户的行为，比如鼠标事件，但是并不仅限于此。
 Models  Models用于存储数据，描绘应用的当前状态。
 Service  Service是应用与外部交互的门户。

下面从Context开始，让我们更深入的探究一下Context和Mediators。Context是整个应用的中心，它提供了一个事件总线，用于应用的其它部分对象之间进行通信。只有在应用启动和初始化时，你才需要处理Context。其它时候你不用理会它，它自己启动，完成自己的工作。[…] Context并不是一个单例对象，为了适应模块化应用的场景，应用可以有多个Context。在这里我们并不打算研究应用的模块化问题，但是鉴于模块化应用是一个很强大的工具，它将会是出现在未来文章中的一个主题。下面让我们来看一个最基本的Context。
[HellowWorldContext.as]

import org.robotlegs.mvcs.Context
public class HelloWorldContext extends Context
{
override public function startup():void
{
//bootstrap here
}
}

复制代码

在自定义的Context中，你需要覆盖startup方法，在Context完成初始化之后，startup方法会被调用。在调用startup方法之前，Context会在幕后实例化所有Robotlegs的核心功能组件，以便接收依赖注入，并且会创建用于应用对象间进行通信的事件分发器。一旦Context被创建，应用便需要对它进行引用。在一个Flex4 Spark应用中，这通常发生在主MXML文件中。如下所示：
[HelloWorld.mxml]

<?xml version="1.0"?>
<s:Application
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:local="*">
<fx:Declarations>
<local:HelloWorldContext contextView="{this}"/>
</fx:Declarations>
</s:Application>

复制代码

因为Context是一个非可视化类，它必须在Declarations标签中进行声明。你应该也注意到了contextView属性与应用本身进行了绑定。[…]这就是对Context的介绍，正如上面提到的，非常简洁，但是在应用的生命周期中它是非常关键的一个角色。当Context准备完毕，我们能添加一些视图组件，通过Robotlegs让它们彼此通信。下面让我们看一下Mediators与应用视图组件之间的关系。
Mediators居于视图组件与应用的其它部分之间，简单一点讲，Mediators负责监听事件。当用户与视图组件交互时或视图组件以某种方式更新时，视图组件会分发事件，这些事件必须被捕获，并且分发到应用的其它部分。有可能是用户点击了一个保存按钮，一些表单信息需要发送到服务器。Mediators监听这些事件，当事件发生时，Mediators收集必要的信息，发送一个事件以便应用的其它部分能用这些数据来执行一些工作。另外，Mediators也监听应用的其它部分分发的事件，如果从服务器接收到一些数据，在进行解析后，Service类会分发一个事件，Mediators是你监听这个事件的地方，并且根据新的数据更新视图组件。下面是一个将获得中介的视图：
[MessageView.mxml]

<?xml version="1.0"?>
<s:TextArea
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
</s:TextArea>

复制代码

这个类非常简短，只是简单地扩展了一下TextArea。为什么不直接使用TextArea呢？因为在使用没有歧义的类时，依赖注入能更好地工作。换句话说，就是通过扩展TextArea而得到MessageView类，我们创建了一个特殊的视图组件来进行依赖注入。这是非常重要的，假如我们的应用有多个用于不同目的的TextArea。通过这种方式来划分类，我们能够清晰地根据用途来定义类，并且允许依赖注入工具更高效地工作。通过MessageView，在将来我们能够增加一些额外的功能。在本例中，它只是一个简单的TextArea，但这正是我们需要的。下面我们来看一下MessageView组件所对应的Mediator。
[MessageViewMediator.as]

import org.robotlegs.mvcs.Mediator;
public class MessageViewMediator extends Mediator
{
[Inject]
public var view:MessageView;
override public function onRegister():void
{
trace("I am registered!");
}
}

目前MessageViewMediator有两个有趣的特征。你马上就能发现第一次使用的[Inject]元数据标签，这个标签被Robotlegs用来标记那些需要执行注入的属性和方法。在Mediator被创建时，被中介的视图组件会被注入Mediator。关于映射被注入的视图组件，你并不需要特别关心，当你映射视图组件到他对应的Mediator后，Robotlegs会帮你照料好一切。一会儿之后，我们将回头看这个问题。我们将首先来关注Mediator的第二个特征，也就是onRegister()方法。
当Mediator完全初始化之后，onRegister()方法为你提供了一个插入点，这个时候注入已经完成，视图组件也已经处于可用状态，典型地你可以添加事件监听器监听视图组件和应用分发的事件。典型地，在创建的每个Mediator中，你应该覆盖这个方法。
现在你已经拥有一个视图组件和Mediator了，它们需要在Context中进行注册或者说映射。我们可以通过MediatorMap完成此操作，顾名思义，MediatorMap负责在Context中映射Mediator和对应的视图组件。另外MediatorMap默认监听contextView的“ADD_TO_STAGE”和”REMOVED_FROM_STAGE”事件，以便自动创建和销毁视图组件对应的Mediator。值得一提是，在图形密集型的应用中，可能会有大量的显示对象，自动创建Mediator可能会导致性能问题，虽然在一般的应用中，自动创建Mediator带来了很多便利而且也很难影响性能。下面我们在HelloWorldContext中映射MessageView和MessageViewMediator。