Spring Roo Impressions
Spring Roo Impressions
Join the DZone community and get the full member experience.Join For Free
At Esberi, we widely used Spring MVC and other products from the SpringSource stable, to build enterprise web applications. Been an RIA consulting company by nature and heavily working on the Flex front-ends, Spring-BlazeDS Integration always comes handy, and regular components like Spring Security, JMS integration and ORM support using Hibernate, are regular nuts and bolts of a generic enterprise web application at Esberi.
The initial part of the project kick-off is spend on Project Configurations, which is kinda tedious to handle during the initial phases due to component versioning. Maven does come to rescue but misses on closed project component templates. This bring us to another exciting yet to mature project from SpringSource called Spring Roo. Spring Roo is RAD development tool, which makes life easy for J2EE developers to work with Spring based project configurations. It helps you build model/domain driven Spring projects and generates the code based on the model/domain specified. Its just not a code generetion tool, but does all the code plumbing to integrate various components like, security, jms, logging, mvc, testing etc. which means the developer concentrates more on the entities rather than component internals.
Spring Roo heavily relies on AspectJ and Maven for most of its behind the curtain scenes. My initial reaction when I got started with Spring Roo was “Holy Grails, it does make life easy.”, but after closing looking at the code generated, its meant for prototyping and not for production deployments (just like Adobe Flash Catalyst design-to-code conversion, ugly and fat). So it does what it promises, and then I had to roll up my blue sleeves to make the code production ready. When working with Spring Roo here are my realizations :
1. The usage scope of Spring Roo is limited, doesn’t makes sense in collaborative enterprise project development.
2. Good for simple data models, not meant for complex ones. Also the domain modeling needs be visually enabled as it is in case of SkyWay Builder.
3. Code back-tracking is a mess, developers just don’t write code in incremental fashion.
4. Hard to sync up code when modified with further Spring Roo generation, generated code overrides your customized code.
5. Been working with Flex/J2EE projects for quite sometime, I am used to DAO design pattern, sadly this is missing in the code generated by Spring Roo, for a good reason, but still I am a spoiled one. Will take some time to accept the change.
6. Generates unit test cases and integration test cases, makes easy for QA and relies on Selenium for web application testing. (GOOD)
7. Generates the web tier for you to perform object CRUD operations, and relies on Tiles framework. (GOOD)
Further I must say Spring Roo does impress me from the point that it makes project configuration easy and the ability to bring in your own add-ons, no more getting paranoid with WEB-INF XMLs and dependency management. Considering the project timeline of Roo, I am sure the best is yet to come, for now limiting its application to prototyping itself.
NOTE: I have still got to put Spring Roo to further testing scenarios. Will write on my experience evolution soon.
Published at DZone with permission of Mohammed Khan . See the original article here.
Opinions expressed by DZone contributors are their own.