Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- I wanted to share some details of Spring Roo in light of specifics
- raised by Skyway's blog entry.
- First of all I'd to help readers of the Skyway blog be able to read
- about Roo for themselves, download a copy and give it a try. Skyway's
- blog didn't include a link, so I will do so here:
- http://www.springframework.org/roo and also
- http://blog.springsource.com/2009/05/01/roo-part-1/.
- Moving onto the technical discussion, Roo does not use Eclipse EMF nor
- Eclipse technologies. Whilst SpringSource is fortuitous to employ some
- significantly talented Eclipse engineers (who lead popular technologies
- like SpringSource Tool Suite (STS), Spring IDE and AJDT), we carefully
- considered the various engineering issues and elected to build Roo
- outside Eclipse. The benefits of this decision include a <3 Mb download
- (not a 100+ Mb download!), compatibility with any IDE a person may wish
- to use (not just Eclipse), the ability to script the tool, the
- significant level of expressive conciseness and productivity possible
- through a text-based UI, a very lightweight and flexible add-on model,
- plus numerous other benefits.
- It's interesting that every modern mainstream RAD framework uses
- text-based UI paradigms (not IDEs like Eclipse). Of course, Roo has full
- Eclipse-based IDE support in the now-free STS product, enabling people
- who prefer to stay solely in their IDE to do so and still enjoy a truly
- first-class experience. The key point is Roo gives you the flexibility
- to use just the IDE, just the text-based UI, or both concurrently.
- A more important point concerns the issues associated with modern code
- generators. I will write an entire blog entry on this topic soon, but in
- the meantime will simply observe that existing code generators generally
- have some limitations in the way that they operate. For example,
- existing code generators emit code in the same compilation units as they
- expect a user to maintain, or emit special "do not touch" compilation
- units that must be maintained by the code generator indefinitely. Some
- code generators prevent the user from editing Java whenever they want
- to, or need to specially mark certain members as "edited". Other times
- code generators insist on being part of a build script, or require you
- to maintain special plugins within your IDE. Some have a questionable
- debugging story, limited SCM integration options, lack flexibility for
- significantly different architectural models plus facilitate an
- explosion of verbose, unnecessary and confusing layers that add little
- value. Existing code generators also generally have a limited to
- non-existent round-trip story, which is fundamentally critical to
- sustainable productivity, and some make it very unclear what is really
- going on. We took all of this (and more that I'll blog about) into
- account when designing Roo, leading to a non-invasive, flexible and
- thoughtful model that uses aspects to ensure we can deliver meaningful
- compilation unit simplification whilst resolving the issues present in
- modern code generators. Aspect-based approaches underpin most modern
- Java technology (including Spring), so it's hardly a big surprise that
- Roo would also use aspects given their repeatedly-proven mainstream
- usefulness.
- The layering technique of a separate DAO/repository, services, domain
- and controller layer also deserves some reflection. Every modern
- mainstream RAD framework places persistence logic within the entity,
- which we believe is perfectly sound and pragmatic, especially in this
- era when JPA transparent persistence and object graph navigation
- undermines most of the initial motivations for dedicated persistence
- layers. In relation to services layers, these act as little more than
- transaction scripts in most practical usages. These transaction scripts
- delegate to so-called domain objects, which themselves are anaemic
- DTO-style objects that generally serve little architectural purpose
- beyond ORM and MVC form backing usage. This does not represent the
- maintainable, encapsulated, efficient OO we all should be striving to
- build, and is certainly inconsistent with the definition and motivation
- of the patterns purported to being observed.
- For the sake of clarity, Roo does let you still write services layers.
- In fact if you are observing the actual architectural intention of
- services layers, they're a very good idea. I wrote a services layer live
- on-stage last week at SpringOne using Roo, so it's not particularly
- complicated � you just create a class as you always have. You can also
- write an add-on that emits a separate repository layer if you really
- believe you simply you must have one. Naturally Roo separates web
- controllers into their own layer by default. Whilst mentioning the web
- tier, I'll also note there is no incompatibility with Spring Web Flow.
- The Spring project team works closely together and naturally ensure all
- projects work well together for the benefit of the community, just as we
- always have. Indeed Spring Web Flow functionality is going to be one of
- the next add-ons we provide out of the box.
- Those concerned about layering should also take much comfort from the
- fact that Roo automatically delivers its users the
- SpringSource-considered best practice for modern enterprise applications
- built in the Java programming language. The people designing these best
- practices have been using Spring, helping the Spring community,
- professionally providing Spring services, speaking at Spring conferences
- and leading various Spring projects since as far back as 2003. Every
- engineering decision within Roo � and the architecture that Roo
- advocates � is underpinned by this significant history of pragmatism,
- community feedback, peer review and engineering integrity. We are
- pleased to debate in great depth any engineering decision associated
- with Roo.
- In conclusion Roo brings the best of usability, productivity,
- flexibility and quality engineering within reach of enterprise Java
- developers everywhere. We solve the numerous problems of traditional
- code generation whilst also delivering SpringSource-considered best
- practice architecture. Given all of this is freely available in a
- lightweight open source project that also includes full IDE integration
- with the now-free STS product, we know the community is absolutely going
- to love it.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement