Flex代码组织结构的一点经验

在开始设计部门内部太极项目二期的时候，就一直在反思一期工作中的哪些不足以及给组内同学带来的痛苦。
其中最让我苦恼的是界面的设计和开发，我很懒，当时在用EXTjs写界面的时候就想，如果每种界面都像VB的程序一样拖拖拉拉就可以搞出一个看似专业的界面就好了。再结合组内同学对界面的恐惧，我征求大家的意见后，决定在二期采用Flex做一个副客户端展示层。
这个决定挺痛苦的，EXTjs刚用熟练，就要扔掉重新去学Flex，而且要重做这个页面，想想都头疼。
我不会Flex，当初用EXTjs也是现学现卖，所以我觉得不用太复杂的技巧和功能的话，学习成本不会大。但有一点我很关注，就是Flex这种需要编译的语言和JavaScript的动态有很大的不同，我在一期设计EXTjs的代码组织方式的时候，得益于JS的动态执行，每个开发者负责一个独立的js文件，所有的事情都在自己这个文件里面做，不管对错，都不影响其它同学。但Flex如何把代码按照业务逻辑分开，这个我想了好久，下面是我最后的设计方案，我觉得可行性还不错，希望熟悉FLEX的前辈能过来指导下。

=========================FLEX代码组织结构========================

我想要做如下的界面，
每个组员负责菜单上的某个功能模块，
每个组员的代码和其它同学的代码完全隔离开，
但要可以和主窗体交互，这就要求每个模块的包中留有给主窗体代码的CallBack接口。
界面、菜单和大体布局如下：




以菜单为切入点讨论下，
我希望每个同学负责一个或几个模块，并且希望他们对每个模块的实现放到自己独立的一个代码文件夹内。
由于各模块的菜单是由各模块的实现者定义的，主窗体无法事先知道，所以必须在主窗体初始化的时候，通过初始化的回调函数得到各个模块的菜单项，然后拼凑起来，再赋值给主窗体的Menu控件展现出去。这里的代码我是这样设计的：

代码的文件结构：



在主窗体代码中这样引用：

   import com.aliyun.taiji.includes.help.*;
   import com.aliyun.taiji.includes.project.*;
   import com.aliyun.taiji.includes.report.*;
   import com.aliyun.taiji.includes.scenario.*;
   import com.aliyun.taiji.includes.session.*;
   import com.aliyun.taiji.includes.user.*;

主窗体加载后的回调函数，这里会做一些初始化菜单的操作：

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" borderColor="#B7BABC" initialize="initMain(event)">

private function initMenu():void{
    trace("主窗体初始化");
    /*
     菜单各模块负责自己的菜单数据
     但必须按照设计者的约定
     使用menu变量保存各模块的菜单XML数据
     * */
    p_menu_root.appendChild(com.aliyun.taiji.includes.help.util.menu);
    p_menu_root.appendChild(com.aliyun.taiji.includes.project.util.menu);
    p_menu_root.appendChild(com.aliyun.taiji.includes.report.util.menu);
    p_menu_root.appendChild(com.aliyun.taiji.includes.scenario.util.menu);
    p_menu_root.appendChild(com.aliyun.taiji.includes.session.util.menu);
    p_menu_root.appendChild(com.aliyun.taiji.includes.user.util.menu);
    
    p_menu_list = p_menu_root.menuitem;
    p_menu.dataProvider = p_menu_list;
    
    trace("输出菜单XMLLIST");
    trace(p_menu_list);
}

在每个模块的代码中都会实现一个叫做menu的静态变量，这个变量统一名称，用来保存各个模块的菜单数据，所以主窗体代码可以在编译的时候就知道，于是可以直接引用。

模块内的menu变量如下：

 public static var menu:XML = 
      <menuitem label="报表管理" ModuleID="3">
         <menuitem label="功能测试报表" ModuleID="3">
           <menuitem label="旺旺客户端" ModuleID="3"/>
           <menuitem label="监控系统" ModuleID="3">
            <menuitem label="准确率测试" CallBackID="1" ModuleID="3"/>
            <menuitem label="算法覆盖率测试" CallBackID="2" ModuleID="3"/>
            <menuitem label="自动化测试" CallBackID="3" ModuleID="3"/>
           </menuitem>
         </menuitem>
         <menuitem label="性能测试报表" ModuleID="3">
           <menuitem label="旺旺客户端" ModuleID="3"/>
           <menuitem label="监控系统" CallBackID="4" ModuleID="3"/>
         </menuitem>
        </menuitem>

这样菜单就可以动态的被拼装起来，无论以后如何更改菜单数据，主窗体的代码无需变动。但是菜单数据有了，每个菜单的动作却是不一样的，为了避免耦合，这是onclick的响应事件一定要由各个模块来完成，但在模块代码变更的时候如何又不影响主窗体代码呢？下面是我的解决方案。

由于用户的行为都是从菜单点击进来的，
所以我给每个模块一个ModuleID,这样主程序可以知道去访问哪个模块的CallBack函数去处理这个点击事件。
但模块是主程序所知道的，各个模块的菜单是由每个模块的负责人自己定义的，不应该放到主程序中处理，否则过于耦合，不方便扩展。
于是每个菜单项的一个ID就被当作CallBack函数的一个参数回传给所属模块，让模块处理自己的每个菜单项事件。不过需要定义这个ID的名字，而且要每个模块统一，这样主程序才能知道如何去访问这个属性，我将它命名为CallBackID。

我将模块按照package来管理，在每个package内实现自己的逻辑，并且提供CallBack函数。
比如点击菜单这个事件就需要CallBack函数来访问对应模块内部的代码处理。
在主程序内我是这样处理的

private function menuEvent(event:MenuEvent):void{
    trace("菜单事件触发");
    /*
     ModuleID用来区分菜单模块
     CallBackID为子菜单项表示，
     由各模块负责人自己定义，需要回传给util.menuCallBack()
     * */
    
    /*
     ModuleID是菜单上每块业务逻辑的ID
     每个util.menu都必须有ModuleID属性，这个是给Flex框架主程序区分菜单模块调用的，
     这个值由崔峥统一分配。
     如下:
     1 => 项目-pronject
     2 => 场景-scenario
     3 => 报表-report
     4 => 用户-user
     5 => 登陆及其他-session
     6 => 帮助-help
     7以后 => 冗余（监控等后续模块）-other
     
     每个util.menu还必须有CallBackID属性，这个是给每个菜单模块响应点击事件的回调函数用的，
     这个值将由各个菜单模块的Owner自行设计。
     * */
    switch(event.item.@ModuleID.toString()){
     case "1":
      west_tree.dataProvider = null;
      break;
     case "2":
      west_tree.dataProvider = null;
      break;
     case "3":
      com.aliyun.taiji.includes.report.util.menuCallBack(event.item.@CallBackID,p_obj_map);
      break;
     case "4":
      west_tree.dataProvider = null;
      break;
     case "5":
      west_tree.dataProvider = null;
      break;
     case "6":
      west_tree.dataProvider = null;
      break;
     case "7":
      west_tree.dataProvider = null;
      break;
     default:
      Alert.show(event.item.@ModuleID+" 不是可用的菜单项。");
    }
    trace(event.item);
   }

点击某一菜单后界面变化：




当菜单点击的时候，主窗体先响应点击事件，得到Event对象的ModuleID后，主窗体就知道给哪个模块的CallBack函数去处理该事件。但模块的子菜单如何处理，并不是主窗体代码能够关心到的，这里就把CallBackID回传过去，让模块的CallBack函数去处理。

拿一个模块的代码举例：

package com.aliyun.taiji.includes.report
{
 import mx.containers.Panel;
 import mx.controls.Tree;
 
 public class util
 {
  private static var west_tree:Tree;
  private static var certain_panel:Panel;
  private static var west_panel:Panel;
  
  public static function menuCallBack(CallBackID:String,obj:Object):void{
   
   if(obj["west_tree"]){
    west_tree = obj["west_tree"];
   }else{
    throw new Error("Report模块 找不到对象 west_tree");
   }
   if(obj["certain_panel"]){
    certain_panel = obj["certain_panel"];
   }else{
    throw new Error("Report模块 找不到对象 certain_panel");
   }
   if(obj["certain_panel"]){
    west_panel = obj["west_panel"];
   }else{
    throw new Error("Report模块 找不到对象 west_panel");
   }
   
   certain_panel.title = "报表";
   
   switch(CallBackID){
    //报表——>功能——>监控系统——>准确率测试(@CallBackID=1)
    case "1":
     west_panel.title = "准确率测试";
     west_tree.dataProvider = treedata_baobiao_shurufa_gongneng_zhunquelv.node;
     break;
    //报表——>性能——>监控系统(@CallBackID=4)
    case "4":
     west_panel.title = "监控系统";
     west_tree.dataProvider = treedata_baobiao_shurufa_xingneng.node;
     break;
    default:
     break;
   }
   
  }
}

主窗体在得到响应事件的时候，就会通过event对象的ModuleID属性和switch分支找到需要处理该事件的模块，然后执行CallBack函数，比如：

com.aliyun.taiji.includes.report.util.menuCallBack(event.item.@CallBackID,p_obj_map);

上面这个代码我们看到CallBack方法中还有其它的参数，这些很重要。
比如我们为了让各个模块的代码操作主窗体，我们必须把它需要操作的控件通过CallBack传进去，否则我们将看不到模块的代码的UI行为。
这里，p_obj_map参数就是这么一个容器，它是主窗体主要控件的一个HASH集合，实现如下：

public var p_obj_map:Object = new Object();
   
   private function initMenu():void{
    trace("主窗体初始化");
   
    /*
     p_obj_map是用来存储给各个菜单模块回调函数参数数据的HASH结构
     使用前务必检查结构体中是否存在需要的对象
     * */
    p_obj_map["west_tree"] = west_tree;
    p_obj_map["west_panel"] = west_panel;
    p_obj_map["certain_panel"] = certain_panel;
    
    trace("遍历回调对象MAP结构");
    var classInfo:Object = ObjectUtil.getClassInfo(p_obj_map);
    for each(var q:QName in classInfo["properties"]){
     trace(q.localName+"=>"+p_obj_map[q.localName]);
    }
    
    /* 若结构中不存在所要对象
     将返回undefined
     * */
    trace(p_obj_map["nil"]);
   }

实际上p_obj_map就是一个Object对象，或者说是个json对象，我在这里将它当作HASH来用，挺方便的。
在p_obj_map被传递回模块内部时，各模块可以通过预先定义好的key键值得到所要的窗体对象，代码如下：

private static var west_tree:Tree;
  private static var certain_panel:Panel;
  private static var west_panel:Panel;
  
  public static function menuCallBack(CallBackID:String,obj:Object):void{
   
   if(obj["west_tree"]){
    west_tree = obj["west_tree"];
   }else{
    throw new Error("Report模块 找不到对象 west_tree");
   }
   if(obj["certain_panel"]){
    certain_panel = obj["certain_panel"];
   }else{
    throw new Error("Report模块 找不到对象 certain_panel");
   }
   if(obj["certain_panel"]){
    west_panel = obj["west_panel"];
   }else{
    throw new Error("Report模块 找不到对象 west_panel");
   }
}

整个Flex的UI代码框架就是这样，好处是各个模块的任何变更都不影响其它模块和主窗体，开发人员可以独立的专注的做自己的事情了。

这种做法很不错。一看就是大应用。俺说下2个应该需要注意的情况：
1. 应用大小：
viewstack 等直接编译进主文件的做法是不可取的。因为这样主文件编译后会很大，局域网除外。

使用Module的话先需要确定Module对主文件大小的影响。
我原来做过实验，单个module编译后，增加主文件20k左右。 但是我没有做 多个module编译后的测试。
如果多个module 编译后文件大小的增量很小在几k上的话，那么就可行。


2. FlashPlayer的内存回收问题 这个很容易被忽视，但是也很重要，尤其是大应用框架。
使用module后 主应用的内存会随着使用逐渐增加。

这个很好理解，因为所有的module都被加载到主程序中，然后在主应用中运行。所以内存会随着使用持续增加，很难被释放。(flashplayer 垃圾回收要求很苛刻)。

要是Adobe AIR的话，也有内存的问题。

jiorry,谢谢你的建议.

我咨询两个问题啊.

1.你说的Module是我所说的那个package么?如果不用package来吧各个模块的代码分开成独立文件,从而让不同的开发人员去单独开发的话,那还有别的方法么?我只找到了package的方法.

2.内存的问题我了解过,谢谢提醒,我一定会提醒开发去注意对象的重利用和销毁.

我在网上看过关于这两点讨论的文章,尤其是说module编译进主文件后加载速度的问题,你写的么?

Regards!

1. 我说的是mx.modules.Module和mx.modules.ModuleLoader。  不晓得是不是你所的package。

2. 我说的Flex内存问题，你再仔细研究一下。
(1). Google一下“Flex垃圾回收”
(2). 用Flex Profiling 查看对象的生成与销毁数量上和内存上的变化。

我有类似的项目，后期发现应用的内存在长时间使用后 暴涨到1G多，整台电脑运行缓慢。仔细优化，不能解决。

例如，原来这样写：

private function showPop():void{
  var pop:MyPop= new MyPop();
  PopUpManager.addPopUp(pop, this, true);
  PopUpManager.centerPopUp(pop);
}

目前pop这样写：

private var pop:MyPop= new MyPop();
private function showPop():void{
  PopUpManager.addPopUp(pop, this, true);
  PopUpManager.centerPopUp(pop);
}

即便pop在PopUpManager.remove后不能释放内存，这样也能保证不再添加垃圾。
pop里也加上了closeThis()

public function clearThis():void{
this.target = null;
this.item = null;
}

即便如此 在flash.system.gc()后还发现有大量垃圾没有被销毁。尤其是create的UI控件。
仔细研究后感觉 Flex UI等控件本身就存在大量对象相互引用，而它使用的是FlashPlayer的垃圾回收器，导致gc不能正确回收Flex创建的UI Object。
所以这是硬伤，不好解决。

谢谢提醒,我们在报表模块会有很多报表对象被加载到主窗体中,这部分存在溢出的风险很大,我尽量控制控件的创建和回收.

不太赞同。菜单应该只由最外层控制，不需要引用那么多模块，整个的菜单应该放在同一个专门的地方配置，除了路径之外，可以考虑配置它的处理模块是哪个，然后到最外层菜单加载了之后再决定。p_menu_root.appendChild固定写了那么多东西，就不灵活了

flex解耦的一般做法应该是事件传递,程序中出现庞大的switch case块和if else块判断进行逻辑判断是否应该值得考虑一下呢？
以下是个人的一点建议,可以考虑使用springactionscript来实现,利用spring ioc来管理mxml和class,例如将meun的dataprovider通过spring来配置,每个模块中的一些属性或者初始化方法都通过配置文件管理. springactionscript集成了cairgorm框架,如果需要触发每个子模块就可以通过cairgorm框架发送event,然后由事先映射的command来执行.每个模块可以根据情况对一个自己的command,command可以用来加载模块或者一些逻辑处理. 如果主界面变动比较少的情况下,可以考虑使用flex liberary project讲这部分程序生成swc包,暴露出一些公共接口给子模块调用.
我比较懒不喜欢多打字,有什么问题大家互相探讨吧.

民工你好啊,
我想模块就这么几个是固定下来了,写死的问题不大,以后基本不会改动.
每个模块的菜单和事件由各个模块的负责人自己去搞,这样的话应该不放在同一个配置里面吧?小弟拙见.



foodyi你好,
后台并没有用spring,而且不打算绑定于java,但你说这个子模块和事件事先映射好的方法我很喜欢,还有你说的cairgorm框架倒是提醒我了,为何不用现有的Flex的框架去做呢,我在之前就没想过一个RIA也会有框架.

谢谢各位的友情提醒,经历了各位的破冰帮助之后,我以后的Flex设计会更成熟一点.但我现在还是很幼稚的,比如有些同学说的话我就没看懂,太菜了.

大家看着有问题就继续指导一下,不胜感激!

还有,报表这块儿也是很头疼的,N多东西,如何重复利用代码和自定义的模块也需要大家指导下.

Regards!

放在统一的地方进行配置是有很多好处的，比如以后要推出定制化产品，屏蔽一些功能，不用改代码，只改配置数据就可以了，又比如遇到产品合并，模块菜单要进行调整，怎么做方便呢？

上面那位兄台说的映射，也是我要表达的意思之一，频繁传递也容易导致耦合度过高，我个人觉得主菜单不应当跟模块有什么交互，它们都应该从服务端读写

我们组开发的时候是单独开发module,然后主页面使用xml文件进行节点配置.
这样每个模块单独开发,采用module进行加载,配置比较灵活些...

内存问题太烦人了...我们现在的程序各个模块点一遍内存就彪高...
viewstack我们尽量不用,都是在titlewindow里需要时才用,viewstack回收实在是...
titlewindow的话注意下还是可以被收掉的.
jiorry说的那个方法也不错但是还是会有一个实例,我觉得还是在写的时候就注意细节,尽量让titlewindow可以被回收掉..