Wednesday, August 4, 2010

Can-Go-ROO Court

Further to my post last year called "It's Easy!" I have started playing around with Spring Roo. Yeah, I know... I may be a sucker for punishment, but I can't resist searching for the holy grail of RAD!

For the un-initiated, ROO is a code generation platform for the Spring Framework. I find it very reminiscent of Ruby on Rails. Do you want to run your unit tests?... Just run the perform tests command. Do you want to change the database you are using?... Just re-run the persistence setup command. Do you want to generate web pages and controllers for your app?... Just run the controller all command. From my perspective, bearing in mind that I have just started using it, some of the best things about ROO are the following:

5 - Command line centric. I find that the command line is often much faster than the IDE. There is something about typing over clicking that just works for me.

4 - Reproducibility. ROO logs all of your commands, so when you want to show someone what you did, or if there is a task that you need to do over and over again, it's easy to pull up a transcript. When I give an example, I will try to include my roo.log in the posting.

3 - Test Driven Development. ROO is very test-aware, and makes testing your work very straight forward.

2 - Aspect Oriented. ROO relies heavily on Aspect Oriented programming. This has many technical reasons for being good, but a beautiful side effect is how clean it leaves the code. There is very little that ROO writes that you can screw up yourself. But if you want to change the way ROO does something, for example take more control in the persistence of an object, just over-ride the persist() method in your code, and ROO will remove it from the aspect code.

1 - No Lock-in. ROO promises an easy transition away from ROO. If you start using ROO and then later decide to "un-Roo" your project, they have a simple set of steps to follow, and voilá, you have a standard Java application.

On the down side, ROO forces you into a Domain Oriented Architecture. If you come from a Service Oriented Architecture background, this can take some getting used to. Now I am not saying here that DOA is worse than SOA, just different. Perhaps at some point in the future, they will find a way to offer both, because in my view they both have strengths and weaknesses.

We'll see how this one fares in the long run, but so far, so good. Part of the exercise this time will be blogging about the journey. This page will serve as an index of sorts. When ever I post an article about Roo, I'll reference it here as well.

No comments:

Post a Comment