项目中使用Spring Roo的经验总结

    自从尝试了Roo的一分钟搭建网页Demo后,我就迷恋于驯服Roo. Roo的使用帮我节省了一部分时间,但同时也带来不少烦恼.
    我在最近两年的四个项目中使用了Spring 的Roo.这四个项目包括:两个后台管理网页,一个社交游戏游戏服务器,一个手机购物系统.

    我主要使用Roo来做两件事:
    1.快速搭建服务器框架
      快速搭建框架主要是使用Roo的Shell生成:
      1.SSH的框架.
      2.构建Domain的CRUD代码(ActiveRecord模式)
    2.自动生成Domain的管理页面
      通过Shell能根据之前已定义的Domain相关的CRUD操作,来生成Domain的管理页面.

 

     项目开发的流程基本:

      1.理解需求

      2.定义Domain的类图,

      3.根据类图,在Roo Shell的生成Domain和页面.

      4. 在现有的代码上做扩展.

 

   通过四个项目的使用,我总结了Roo的以下优缺点:

 

    优点:
       前期开发速度快
       Roo最大的卖点就是自动化.这也是我使用Roo的主要原因.以上两点都是通过简单的命令行方式来建立Domain.并在建立的同时自动生成代码.在需求明确后的项目的前期.可以快速生成可以运行的简单界面来作为演示.

    缺点:

    1.后期维护成本高.
      这里的维护成本表现在五个方面:
       1.Roo默认采用ActiveRecord模式,便于代码的自动生成.我们可以在前期的Controller中直接对Domain进行save或者update. 但ActiveRecord模式的弊端是,当业务需求变的越来越复杂时,Domain中的方法越来越多,Domain越来越臃肿,我们不得重新建立Service层甚至Dao层,将业务从Domain中剥离.当我们拥有几十个,甚至上百个这样的Domain时,这时候再进行相应的重构.难度将非常大(我最后尝试成功了.但确很艰辛).
       2.Roo生成的页面可扩展性很差.Roo在前端页面中使用了目前已不是主流的dojo进行动态效果展示.并通过Roo自己的Tag来生成相应的表单页面.Roo使用Tile来管理页面布局.强制页面支持国际化,使用Roo的Tag必须编辑相应的properties文件.
       3.Roo生成大量aspectJ文件在IDE中的自动构建中所消耗的时间会让人抓狂.尤其是当项目中有上百个domain的时候.这样会经常中断程序员写代码的思路. 这时候最明智的办法是关闭自动构建.
       4.很难多人协作,更新Domain后,roo会自动更新对应的jsp页面,会轻易的将页面更新的面目全非.
       5.Roo对中文支持不好.当代码中出现中文时,可能有很高的机率导致roo shell的崩溃.作为一个使用者,我把bug提交给roo的维护者,希望他能解决时,得到答复却是Roo没有支持中文的计划.

 

     2.性能低下
       1.当多个Domain的引用关系比较复杂时, 使用Roo默认建模的方式.Roo将会为其生成JPA的一对多,多对多等关系.这样生成页面前获取Domain的数据,都会尝试填充关联Domain的关系数据,对数据库进行N+1操作.由于自动生成页面的原因.必须对页面改造后.才能使用lazy模式.
       2.Roo使用JPA来进行ORM映射, 当系统对Java对象实例的唯一性比较敏感时,可能会遇到性能问题.JPA的实现Hibernate由于设计的原因.通过Key获取Domain时,每次都会生成一个新的对象.即使使用了二级缓存,也解决不了这个问题.

     通过以上总结.我个人建议,当你的项目满足以下情况才应该考虑适用Roo:
        1.微型项目,当domain不超过10个时.
        2.项目中的前期Demo(Demo完尽早剥离Roo)
        3.想给别人炫耀如何一分钟搭建网站时.

      PS, 我之前四个使用过Roo的项目,除了一个简单的后台管理系统没有变化外,其余项目都已通过改造将Roo剥离了出来(过程很痛苦).