Wednesday, July 22, 2009

Spring Roo vs Grails generated controllers



As I already tweeted earlier today I was trying out Spring Roo 1.0.0.RC1 as it was released today.

After playing a couple of hours with Roo I must say really like Roo using AspectJ inter-type declarations (ITDs). For example Roo will automaitcally generate id and version fields and getters and setters for your persistent fields in your domain class. Roo generates these at development time in separate AspectJ .aj files. As a developer you won't touch them as Roo will manage and update them automatically as you add fields etc. to domain classes. The great thing is the generated code will not interfere with your custom code and you don't have to be scared you custom or overwritten methods are overwritten by Roo again. During compilation all .aj files belonging to the Java class are compiled into just 1 .class file.

What I really liked is that when you are developing in SpringSource Tool Suite (based on Eclipse) code completion works also for methods contained in the AspectJ .aj files. So also debugging your code is a real breech as you can step through the methods generated by Roo easily.

Roo also contains scaffolding. However as a long term Grails user I got scared when I saw the controller code generated by Roo. See the example below:

Roo generated controller code:


@org.springframework.web.bind.annotation.RequestMapping(value = "/nation", method = org.springframework.web.bind.annotation.RequestMethod.GET)
public java.lang.String NationController.list(org.springframework.ui.ModelMap modelMap) {
modelMap.addAttribute("nations", com.footdex.domain.Nation.findAllNations());
return "nation/list";
}


Grails generated controller code:

def list = {
params.max = Math.min(params.max ? params.max.toInteger() : 10, 100)
[nationList: Nation.list(params), nationTotal: Nation.count()]
}


OK, the Roo generated code could look better if we remove all the package information before the classes:

@RequestMapping(value = "/nation", method = RequestMethod.GET)
public String list(ModelMap modelMap) {
modelMap.addAttribute("nations", Nation.findAllNations());
return "nation/list";
}


But then we should also just create the same functionality in the Grails controller (without paging):

def list = {
[nationList: Nation.list()]
}


So which one do you prefer?

I really think Spring Roo will have a great future. The use of ITDs for generated code and it's support in SpringSource Tool Suite will really aid adoption. Also in case Grails is not allowed within your company, Roo could really help you to get more productive.

As I expressed already in my example I really like Grails/Groovy effectiveness and readiness of code. Also the deep level of code by convention empowered by Grails is unbeatable.

With Grails and Roo, SpringSource has 2 remarkable frameworks in it's portfolio. Let them be as innovative as always and we as developers are the winners!

8 comments:

Alvaro Sanchez-Mariscal said...

It would be great if SpringSource invested more in Grails (eg: IDE's, hiring more core developers, etc) rather than creating a similar (probably better in some scenarios, but similar) framework.

Masiar Ighani said...

SpringSource should really invest more resources in enhancing Grails than building another framework...
I think the argument: "If you are not allowed using Grails in your Company, use ROO" is not valid. As Roo has its own learning curve like any other framework. Managers make descisions based on cost effectiveness, learning curve, protection of investments and few others. And ROO is definitely competing with Grails. And having two Agile Frameworks in the product portfolio is confusing developers. SpringSource: DECIDE!

Anonymous said...

Roo now generates ITDs that use proper imported types, so they look quite natural. So one of your concerns about Roo has been fixed as of Roo 1.0.0.RC2 and above: http://jira.springframework.org/browse/ROO-177

The other item to note is the code Roo generates is 100% standard Spring/JPA/JSP/Maven etc. This means there is zero learning curve for anyone already experienced with the normal Java stack. Finally, with Roo you can "push in refactor" and get rid of Roo from the project in < 3 minutes. You're left with stock-standard Java code just as if you'd written it yourself.

Roo also does not exist in the runtime. So a Roo app is going to be very fast and memory efficient. Plus its use of AspectJ compile-time weaving means there aren't even AOP proxies needed, resulting in further performance and memory optimizations.

Vernon Singleton said...

Is their any documentation you would recommend for writing a plugin for roo?

Marcel Overdijk said...

@Vernon: Spring Roo 1.0.0.RC3 contains reference documentation. Check out part III. Internals and Add-On Development

Vernon Singleton said...

Is there any documentation you would recommend for writing a new plugin for roo?

Franki said...

I'm a Grails developer. I would prefer SpringSource unify efforts in a more powerful framework rather than disperse in two frameworks. What is the motivation for Roo?

Marcel Overdijk said...

@Franki: I think mainly for people who can't use Groovy/Grails because of company restrictions.