WorkerBee开发框架说明
<一>概述
一、目的：
Workerbee是针对使用flash pro和纯as开发的中小型项目建立的，目的是提供一个合理的项目结构，灵活可复用的代码，从而提高开发效率，降低一些bug的出现几率。
简而言之：结构清晰，灵活可复用，轻量，提高开发效率，降低bug。
二、使用环境：
Flash pro和as开发的项目。
三、针对项目类型
中小型项目，例如：flash网站，交互式应用，小游戏等。不适用于大型项目（页游、企业级管理应用等等）和微型项目（flash效果，广告动画等）。
大型项目中，对模块化设计，性能表现，ui库都有较高和严格要求，workerBee相对简单，从而无法胜任。
微型项目中，与外部交互少或者没有，实际实现代码量底，使用框架，会造成冗余。
四、组成部分：
框架主体有四个部分组成，分别是：
1.显示层容器对象。
2.Interactive交互类对象。
3.Service服务对象。
4.Events事件对象。
其他附属结构，包括：
1.ui对像。
2.figure图形对象。
3.Figure图形样式数据集合。
4.Skin皮肤。
5.Vo常用数据集合
6.实用工具
五、设计思路：
框架设计来源于MVC思想，但相对pureMVC框架和其他一些框架要简单很多，同时一些部分又有别于mvc。总体概述为：三层四个部分。
具体分为：UI显示层容器部分，interactive部分，service部分，event部分。
权限：为了规范各个部分的责任和功能，保持清晰的结构，引入了权限的概念。表现为一些对象只能由特定的对象去创建和访问，权限的级别不同，能够创建和访问的对象不同。高级别的对象可以直接或者间接控制低级别对象的公开方法和运行中的作用。低级别的对象只能控制自己或者访问更低对象的接口，能够通过事件上报高级对象加以影响，但不可以直接调用高级对象。事件的传输也遵循权限规则。一个部分中下级对象可以通过事件向同一部分的高级对象反映状态情况，但一般不可以向其他部分发送事件。
1.UI显示层容器部分
UI显示层中的容器类型、document类型主要完成构建项目界面，提供对显示列表中对象的控制。通过interactive和服务对象进行交互，参与流程的控制。
容器类是权限较高的类（document类算作根级容器，因此他的权限在框架中最高），他可以直接调动子容器和ui对象的公开方法，操作属性实现交互过程中的显示行为，并在合适的时候通过interactive间接调动服务层，实现数据交互。在一些小型项目中，当interactives省略时，可以直接操作服务层。
容器类的主要任务是操作显示列表，调动各个需要的容器类，以及在合适的时候通过interactive类与服务层交互，完成交互任务。
在显示列表中，显示对象按照父子级关系建立，本身具有一定的耦合性，如果抛开这种关系，通过外部独立控制层进行管理，会使结构趋于复杂（对中小型项目而言），耦合性管理和消息的传输的把控难度加大。所以利用根级容器和核心容器同其他显示对象的天然联系建立信息传输和流程控制，有现成的通道可以利用。并且父级容器直接操作子级容器，子级容器通过事件上报父级容器，可以降低内存溢出出现的几率。
UI中的非核心容器和其他显示部分完成一般显示对象的任务，例如展示数据，动画效果，界面样式和基本功能。
2.Interactive部分
Interactive部分是权限次于容器类的逻辑层，他主要负责协同容器类特别是文档类与服务层交互，并且将获取的数据进行处理，分派，对流程加以控制。
Interactive类可以调动想要调动的服务层类的开放接口，并接收服务层返回的数据。通知容器类该如何操作以更新显示层的状态。但是，交互类不能直接获得显示列表中对象的引用，虽然高级的交互类持有文档类或根级容器的引用，但不推荐通过该引用直接操作显示列表中的对象，可以使用event部分的相关内容间接调动显示对象，从而把握流程。并不是所有的类都可以创建interactive，只有容器类型和文档类类型才可以创建。
如果说框架有控制层，那分别是由根级容器类，子级容器类和交互类构成，容器类完成显示层的控制，交互类完成模型层的控制，容器类直接同交互类沟通，交互类通过事件提醒容器类要做什么，对运行流程加以控制。容器类可以直接创建交互类，交互类不能直接使用容器类的引用。因此，交互类的权限低于容器类。
对于中小型项目，mvc三层结构尤其是PureMVC过于复杂了，会造成很多冗余代码，即逻辑代码没有框架代码多，而且理解不透或使用不当，反而造成结构不清晰。但是没有控制层，单纯由根级或核心容器类兼任控制层的任务，又权限过高，造成控制显示层的方法与控制模型层的方法相互交错，不利于维护。同样逻辑判断和流程控制都集中在某个或几个模型类中，会造成他的权限过高，针对性增强而复用性降低。因此创建interactive提供了一种选择。他具有服务类处理数据的权限又有控制流程的能力，但是却没有直接控制显示层的权限，只有沟通和提醒的权力。通过它和核心容器类相协调，共同完成控制的任务，可以降低容器类的权限，集中数据和流程的控制。达到结构清晰不推高耦合性的目的。
3.Service部分
Service完成类似mvc中model层任务，他也是经常创建和使用vo的部分之一。
Service服务类负责与数据、资源相关的任务，例如：http请求，获取flashvars，和js交互，加载本地资源，文件，图片和swf等。也可以做一些数据处理保存，为流程控制提供数据等任务。创建service类同样需要权限，只用容器类，文档类，交互类可以直接创建服务类。
Service的重点在于提供而不在于控制。可以创建用于加工数据和资源的类以及功能，并且按照流程中的时间点提供数据，但是不应对流程的管理加以影响。就是说，可以报告给交互类和容器，哪些任务完成了哪些没完成，让他们对情况加以处理，但是不能由service发出指令来让系统进行哪一步操作。
4.events事件部分
Event部分负责在3个主要逻辑部分中传递数据和消息。
容器类，交互类，服务类以及显示对象之间传输数据主要依靠事件（event）部分，他由一些不同类型的事件类和一个单例的事件转发者构成。事件的传输和发送需要遵循一定的规则。例如：处于同一显示列表中的显示对象，子级可以通过事件与父级交互，也可以向更高级乃至根级发送事件，但不可以直接操纵父级属性和引用，也不可以发事件给服务类和交互类，除非是属于显示列表中的核心容器（不一定是根级容器）。
事件转发者主要用于在三层之间做一些必要的间接交互工作，他的创建也收到权限的控制。只有容器类，文档类，交互类，服务类可以创建转发者。其中交互类和服务类必然含有事件转发者，容器类不一定要创建转发者，但是，文档类应当含有转发者。事件转发者可以有效的在三层之间建立沟通关系，并且是松散耦合的。但是过度的使用转发者却是不可取的，因为一方面他是单例模式，一个与某次交互不相关的对象却可以通过它来接受事件是不对的。另一方面，过多的类使用转发者破坏了原有层级的上报机制，加强了系统结构中相距较远的对象之间的关系，间接推高了耦合性。不利于维护和扩展。
六、图形、样式和皮肤
图形，样式和皮肤主要是对ui包中的显示对象进行修饰用的。
图形包提供了一些对象和方法进行图形绘制，他利用样式包中提供对应样式参数，使用as3绘图API进行绘制。
样式包提供了许多样式对象，本质类似于数据集合对象（ValueObject），对象中没有方法，只有各种属性用来保存与显示状态有关的值和对象。
皮肤包是对样式对象的组合定制。可以使用皮肤的ui组件都有一个skinClassPath和skin属性，用来指定使用的皮肤文件。文件中包含了ui组件中用到的显示对象的样式设置和对特定对象的设定（例如：在按钮中的皮肤文件中有属性标识是否使用文本框，即按钮中的label，对于容器来说，皮肤中有标识决定是否使用背景图）。
Ui对象使用皮肤，皮肤定制样式设置，样式中的参数用于计算和渲染外观用到的图形对象。这就是几个对象之间的关系。
七、ValueObject对象
Vo对象是框架中重要的组成部分，他提供的一些类中包含很多属性和少量方法（不推荐vo中含有大量和复杂处理数据的方法，这些应该交给服务类和交互类来做）。容器类，交互类和服务类之间交换大量数据或者特定数据时都是用vo包中对象。推荐在具体的项目中，三个逻辑层之间遇到类似object数据时也使用vo对象（创建一个特定的vo）。
八、实用工具
实用工具提供了一些和主体设计无关，但在开发中提供便利的工具类，比如颜色分解合成，以及其他特殊算法集合等文件。
