Rebotlegs

Robotlegs 进阶开发笔记【转】

【本文属于转载，阅读原文：http://www.wersling.com/?p=675】 Robotlegs是一个很独特的MVCS框架，2年前我开始使用它，并用于一些项目中，那个时候Robotlegs还是bate版本，现在已经更新到1.4，更多的人已经开始学习它并用到项目中。在学习和使用过程中，我整理和体会到一些有用的知识点，希望和正在学习和使用Robotlegs的同学分享。 因为是进阶内容，因此，建议对Robotlegs还在入门阶段或没有使用它到项目中的同学先看看这些内容，会对你更好的理解后面的内容有帮助。当然，如果你对Robotlegs已经熟悉，可以跳过。

恩，如果你有所了解了，我们开始后面的内容。 Robotlegs代码包结构组织：

  1. [domain.lib]
  2.     various utilities
  3. [domain.project]
  4.     [projectmodule]
  5.         [model]
  6.             [events]
  7.             [vo]
  8.             ProjectModuleStateModel
  9.         [view]
  10.             [events]
  11.             [renderers]
  12.             [skins]
  13.             MyProjectModuleView
  14.             MyProjectModuleViewMediator
  15.         [controller]
  16.             [startup]
  17.             MyProjectModuleActionCommand
  18.         [service]
  19.             [helpers]
  20.             MyProjectModuleService
  21.             IProjectModuleService
  22.         [signals]
  23.     [projectmodule]
  24.         [model]
  25.             [events]
  26.             [vo]
  27.             ProjectModuleStateModel
  28.         [view]
  29.             [events]
  30.             [renderers]
  31.             [skins]
  32.             MyProjectModuleView
  33.             MyProjectModuleViewMediator
  34.         [controller]
  35.             [startup]
  36.             MyProjectModuleActionCommand
  37.         [service]
  38.             [helpers]
  39.             MyProjectModuleService
  40.             IProjectModuleService
  41.         [signals]
  42.     …

  这是Joel Hooks建议的包结构，我作一些修改和说明：

  • 这是一个多模块情况的包结构，如果是单模块，可以少去projectmodule这一层。
  • [signals]包不是必须的，除非你用到了Signals。
  • 把每个模块要都用到的公共代码放到[domain.lib]下。模块和模块内代码保证独立，不会相互使用（引用，实例化）。
  • StartupCommand 内代码建议以MVC结构分离。如果一个模块中StartupCommnad内有过多代码，建议把它拆分成 ModelStartupCommand，ControllerStartupCommand和ViewStartupCommand，这样职责更清晰。
  • [controller]和[view]中，如果有很多类，建议按照功能建立子目录
  • 这些目录看上去如此之多，我可不想一个一个创建，因此，我写了一个Ruby小脚本，用于创建这些目录和基础代码，有兴趣的可以看看。

边界与约定：

  • 避免在Proxy中注入其他Proxy和Service，尤其不要侦听他们的事件。
  • 避免Proxy采用单例模式，而是采用Robotlegs的injector.mapSingleton方法，单例意味着任何类成员都可以访问和修改，这会增加代码的复杂度和维护成本。
  • 非必要，避免将View或Mediator存入Proxy。
  • 建议在Mediator中只获取Proxy的数据，而不设置或管理数据。
  • PopupWindow（如果它被添加到stage）建议在Mediator中实例化，这有利于手动构造Mediator和侦听事件。
  • 非必要，避免使用viewMap。它会使View绕过Mediator而直接与数据层交互。
  • 避免在Command中注入一个View或Mediator。
  • Service的方法建议在Command中调用，而不是在Mediator中，这样可以更好的复用。当然，一个简单的方法是可以接受的。
  • 最后一条：Service只是负责将加载的数据通知（dispatch event）出去，自己并不存储数据。

多模块： Robotlegs提供一个多模块工具：robotlegs-utilities-Modular。可以方便的进行模块和模块之间的通信。它看上去十分优雅，用起来也十分方便。下面是几点要注意的地方：

  • 尽量将模块内事件和模块间的事件分开，不要混杂着用，我定义了一个IModuleEvent接口，用于区分它们。
  • 所有需要公用的对象或类（VO，Proxy，Service）都在主模块的Startup时注入，这样子模块都可以很方便的用到。

开发效率： Robotlegs的底耦合和清晰的职责被人称赞，实现一个功能需要的类文件之多也使其他MVC框架望其项背。^_^’ 因此在开发过程中，也许你会烦躁那些重复的操作——创建众多的类文件。

  • 采用Signals可以有效减少View-Mediator的事件对象，其效率高于事件机制。CommandSignals也可以用Signals驱动，但是不会节省你的类文件数量。
  • 采用代码模板功能快速生成代码。如果你连这个模板都不想写，有热心人已经帮你创建了不少：Flash Builder，FTD，FlashDevelop。
  • Robotlegs的状态机（StateMachine），和PureMVC的状态机类似。在处理带有状态或流程的操作中很有用，比如与服务器连接状态、多步骤的表单提交、带条件判断的问卷调查等等。
  • 不一定在项目过程中完全贯彻使用MVC框架，尤其是在WebGame项目中，可以把功能单一的部分做成一个组件，对外提供接口就可以。比如场景渲染引擎、寻路算法、播放器等。看上去就像在使用一个第三分工具库一样。
  • 由于Robotlegs职责分明，因此可以根据MVCS的来分工：
    • 由团队中一部分人来维护服务层（Service）代码，专门处理数据加载和与服务器通信代码编写。
    • 一部分人处理公共数据层代码（Proxy）
    • 一部分人处理界面层代码（View）
    • 一部分人处理业务逻辑，连接数据与界面（Mediator，Command）。这样带来的好处在于一个人只要专注一个部分，因此有更多尽力关注稳定性和性能；坏处是有时会觉得比较无聊，因此时不时要切换着来做不同的部分。小项目中，也许就一个人，是没有办法这样实施的，但是项目大了，完全有必要尝试这样的方式。最后还啰嗦下，很多新人刚刚进入项目，如果对Robotlegs不了解，让他从View层开始开发，有利于学习和确保他更快融入团队。

内存管理（GC）： Robotlegs的低耦合性带来的就是优雅的GC，只要是遵循以下原则，内存泄露可以很好的解决，哪怕在复杂的项目也可以：

  • 严格遵守前面提到的【边界与约定】。
  • 为每一个View实现一个dispose方法（确保这个方法真的可以GC所有View内实例和引用），并在Mediator的onRemove方法中调用。
  • 每个模块实现ShutdownCommand，进行与StartupCommand相反的操作。
  • 为每个Actor（Proxy和Service）实现dispose方法，并在ShutdownCommand时调用。

性能： 很多框架用到后面，都会带来或多或少的性能问题，Robotlegs也不例外。建议试试我提出的几个方法：

  • 只要执行一次的Command设置oneshot = true。示例：

    1. commandMap.mapEvent(“eventType”, MyCommand, EventClass, true);

      复制代码

  • 在添加大量Sprite到舞台前，可以设置：mediatorMap.enabled=false；。完成后再设置为true，这样可以避免MediatorMap侦听到ADDED_TO_STAGE事件后频繁进行不必要的操作。也可以使用robotlegs-utilities-LazyMediator来解决这个部分的性能问题。
  • 将一些对性能要求极高的部分写成独立的组件。

必须承认，Robotlegs的学习成本要比PureMVC等框架要高，也复杂一些。还有很多人不喜欢Inject方式，但是我要说，Robotlegs 绝对值得你去尝试。在项目开发中不断的学习和探索，将是一个十分有趣的过程。衷心希望有更多人学习和使用Robotlegs，也分享更多的经验。