使用Spring Roo ，感受ROR式的开发

感觉是Grails把Groovy的外壳剥了就是roo了。

ROO框架使用Aspect来描述像@Configurable这样的注解。在Roo框架中使用AOP背后的理由是什么？

至于为什么我们使用aspect作为Java代码生成的基础，背后有许多动机，我在我的系列博文的第三部分谈到了这一内容。但是实质上我提供了一些不同的备选技术原型，包括JSR 269、构建时生成源代码、IDE插件、开发时产生字节码、运行时产生字节码以及高级反射方法如扩展Spring Framework AOP、DSL等等。

我优先要考虑的事情是确保：
就算用户停止使用这一工具，他们的项目照样能够进行；这直接就排除了采取任何运行时动作的可能性。
在运行时，用户的项目必须不以牺牲性能为代价；这直接排除了大多数反射方法的可能性。
开发者要能够使用他们已有的Java知识、技巧和经历。于是工具必须支持常规Java编程体验、支持开发者的普通编程形式、使他们可以使用自己常用的IDE，访问熟悉的工具如debugger和代码助手。该工具必须能使开发者运用已知、已理解及所期望的东西。这样就排除了任何特定的字节码方法以及大多数运行时方法。
该工具必须能自动工作，并且不需要明确调用，也不需要系统集成或建造特定IDE。它必须绝对支持透明的、即时的round-tripping。这就排除了JSR 269以及构创建于系统等方法，比如类似于XDoclet的工具。
其次要考虑：
用户的项目必须工作于Java 5及更高版本上。这就排除了JSR 269，将其排除的原因还有很多（比如原型时期脆弱的IDE支持）。
该工具应该容易让最终用户进行扩展。当然，由于我们使用了AspectJ技术，这是件非常容易的事。它还不鼓励使用任何特定IDE的技术，这可能比Roo附加组件需要更复杂的开发和部署过程。
该工具对增加附加组件的支持应该是长期的。使用AspectJ ITD提供的分离概念可以很容易的实现这一点。
该工具应该非常轻量级：下载、学习、运转都应非常迅速。这对一个拥有最少依赖的基于shell的方法非常有利。Roo 下载文件小于3M！
实质上AspectJ ITDs增加了一个自动维护的元数据模型，它是我们能找到的唯一解决方案，可以满足所有需求。当然，如果你愿意牺牲一些表达方面的要求的话，自然会有其他方法解决这一问题。

批评两句.雕虫小极而已.

也许这么做开始的时候能省点力气.可是等到一年以后你来维护这些代码的时候,是不是还能象现在这么高兴呢?想想这个问题吧,如果答案是否定的,那么就趁早放弃吧.

其实这是一种程序员常有的误区

问题是，你如果比较好的掌握了它，你根本就不需要再去看生成后的代码，除非是库本身有BUG。这种可能性不排除，也许你会说，到时候调试查错困难，但是相对于它给你减少的代码和工作量从而提高的效率，从而减少的潜在BUG，比因它自己可能的BUG给你带来的阻碍，应该更多吧？
软件开发就是这种方向，复杂性越来越高，只能抽象等级也越来越高。