做大型flex项目的一点经验之谈

怎么才算大型呢，在我看来应该有三四十个类以上吧，多少行不好说，我还是倾向于简洁美的（动不动什么上w行的没有意义）。本人还算有点小运气，基于as2,as3,air的都做过些，下面就拿些个人经验探讨探讨。

• 尽量别写老长老长的类。呵呵，许多关于设计模式的书都提到过些，每个类应力求精简干净，功能单一。
• MVC。这是一个听得烂的词了。由于flex有很大一部份是UI和UI相关的操作，所以这个词的作用任然非常大。很多情况下，V和C容易分开，我 的一般做法是mxml代表View，而Controller独立写类，他们之间是组合关系。一般来讲系统外部操作（包括用户操作，UI的一些事件，但是于 后台交互的事件不属于此，后面会讲到）首先会从mxml上反应（比如button的click响应函数），然后mxml再调用controller的方 法。这时候大量的运用绑定特性（bind）是一个不错的主意，同时注意controller类应该多提供getter方法来给mxml做绑定。 getter方法的好处，一个是只读，第二个是可扩展性，试想想，如果你就用一个public属性做绑定，那么这个属性实际上已经被定死了。这样的一个体 系就能大致形成controller操控UI的一个局面，而且解藕性是比较好的。
• 少用点addEventListener。如果用的多了容易失控。大系统的逻辑关系一般都很复杂，而addEventListener做响应函数 调用非常有可能被遗忘掉（比如某些情况下不需要响应），最后测试找bug很痛苦。其实我觉得有一个很土的办法，就是把响应函数直接给抛出事件的类，那样基 本上当你想抛出事件的时候也会注意到谁会来响应了。
• 分离出若干个设置类（一般存放基本配置参数），全局常量类（比如URL，路径等等），专门处理后代数据交换的类（分离flex主体和后台，这样无论想切换到测试服务器，或者切换交换协议都比较方便）。
• 做好Log工作。我是不大相信test case之类的玩意儿的，flex以UI为主不适合这些，而且很多毛病会出在集成测试里，因此flex builder debug基本上也不会派上用场。这时候Log就是没有选择的选择了。flex自带的Log系列就比较好，只是需要自己扩展输出目标。
• ANT。单一个flex不成一个系统，构建工具在集成测试的时候内给你剩很多时间（如果你喜欢自己build,copy/paste那也行）。我一直用ANT的，这是一个很不错的工具。
• 版本控制。即使一个人干，也应该需要版本控制的，不为什么。防止你想找后悔药吃的时候找不到。这点我感触很深，刚开始工作的时候也觉得这些虚招子特别烦。版本控制就好像买保险一样，关键时候就发挥威力了。