Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

[TSE] Hop into Real Object Oriented (ROO) with Ben Alex

This session's goals are to:

  • To detail the "ROO" DDD architecture
  • To show you how productive ROO can be
  • To profile an Australian project using ROO

ROO is more of an implementation than an architecture. So what is ROO? It's not an Australian marsupial or an Australian airline. It's a Domain-Driven Design (DDD) implementation.

Real Object Oriented (ROO) is both an architectural approach and a framework with code generation. ROO uses 4 (UI, middle-tier, domain model and persistence) layers instead of 3. Most of of the code is in the domain model. In the persistence layer, most DAOs only differ in finder methods. Rather than DAOs, "Repositories" (from DDD) are used.

Since most of the code is in the middle-tier DO layer (including business), the middle-tier is primarily used to "export" interfaces for remoting, the middle-tier facade and DTOs. Almost all of the interfaces in the ROO architecture are generated or require trivial coding.

Compare ROO to Traditional Approach (normal way people develop with Spring).

  • Transparent persistence usually not used , it is in ROO
  • Persistence layer name: DAO, Repository in ROO
  • Finder method location: DAO, Finders in ROO
  • State integrity: None, DO layer in ROO
  • Business logic: Service Layer, DO Layer in ROO
  • Form backing objects: "DO" layer, DTO layer in ROO
  • DO and SL pattern names: Misused, Correct in ROO

ROO uses more layers and types than traditional Java. Traditional Java isn’t a fair comparison (patterns are not very OO, and can be less efficient). Ben believes the ROO approach is justifiable for 3 reasons:

  • Layers have well-defined purpose (OO justification)
  • Types mostly auto-generated (efficiency justification)
  • Architecture uses patterns (precedence justification)

Patterns used in ROO:

  • Strategy
  • Façade
  • Domain Object (“DO”)
  • Data Transfer Object (“DTO”)
  • DTO Assembler
  • Repository

There are many problem with code generation, but quality code generation is attainable.

How is ROO different from other things?
It was designed to scratch an itch. Ben wrote it because he was tired of writing code using the same old architecture patterns. He didn't write it because he wanted to start another open source project. It was also designed to scratch other people's itch (do we really need the service layer?). ROO is founded on a few philosophies: domain first, infrastructure 2nd, convention over configuration, embrace OO and modern capabilities.

Ben is now doing a video demo of ROO. In the video, he's created a project using a Maven 2 archetype (I've seen this used a lot at this conference) and imported it into Eclipse. From there, he creates Entity classes and shows how Eclipse generates Hibernate mapping files and DTOs (as well as tests) for the entities. The one pain (currently) is you do have to copy the generated mapping files back into your classpath. Most of the POJOs that Ben is creating for his domain model extend some ROO parent classes (i.e. AbstractDomainObjectLong). While he does write getters in these classes, he only provides setters for those fields that can change. Then he creates a public constructor that contains the required fields.

It looks like Ben has wired up some sort of external tool (or maybe a Maven plugin) to do the code generation. Later I found out it's Java class that's merely run from Eclipse or Maven. ROO is Java 1.3 compatible.

For the tests that ROO generates, it creates abstract methods for any business logic methods that need testing. It's then up to you to subclass this test and implement the abstract test method. ROO also seems to generate population classes that populate your database for tests. I don't know how it figures out sample address information, but I'm assuming this data somehow existed in the Maven archetype.

To create Finders with ROO, you implement a FinderSpecification class and implement a public FinderDetails[] getFinderDetails() method. The code in this method is more like EasyMock's API than Hibernate's Criteria API.

For the code generation, the life of a type is very important. Not only are types created initially, they're updated when you touch them. Some class are generated as Abstract classes when they need you to provide additional information.

ROO generates custom finders, classes, and the Spring XML. It does not generate Hibernate User Type interfaces, but it does generate classes for user types. It generates DTOs, middle-tier facades, classes and Spring XML. It also generates test data and tests for all the generated code.

Ben just did a survey of the room asking who's using Ant vs. Maven. Surprisingly, Ant only slightly beats Maven.

Persistence in ROO

Key Principles:

  • Think of them as DAOs with transparent persistence
  • Transparent persistence engine is essential
  • Domain objects always attached to unit of work (UoW)
  • Persistence layer may be injected into domain objects (although mostly finder types will be injected, not repositories)
  • Persistence layer is unaware of DTOs

The Repository:

  • Global, shared repository
  • Transparent persistence, API agnostic interface
  • Method naming convention (read*, find* and make*)
  • Some methods exported to middle tier facade

Finders:

  • Typically fine grained and domain object specific
    • public User[] findUserBySurname(String surname) )
  • Easy to dynamically mock and DI
  • Returns domain objects attached to UoW
  • ROO generates finder via criteria-like API

Middle Tier Exporting

  • Repository contributes its read* methods to facade
  • Finders contribute all methods
  • Facades returns DTOs
    • Not domain objects
    • Conversion via DTO Assembler
    • DTOs are normal JavaBeans
    • DTOs lack lazy loading semantics

Domain Objects

Key Principles:

  • Most of your work and code occurs in domain objects
  • Domain objects are your only 1st class citizens
  • Code generation is mostly driven by domain objects
  • DI is certainly possible

Encapsulation:

  • Fully encapsulated
  • Distinguish state managed fields
  • Persistence layer uses field-level access
  • Public constructors reflect mandatory fields

For the DTO Assembler in ROO, they use Dozer. Initially, they had a fair amount of issues with it, but the latest releases have solved all of those.

In addition to the code generation for DTOs, Facades, etc., ROO generates middle-tier metadata that's all available via JMX. There is enough information provided by this metadata to build a Naked Objects implementation (or possibly even a web UI).

Interestingly enough - it looks like the Maven archetype for this project is able to manipulate the launchers and external tools that are configured in Eclipse. I confirmed with Ben afterwards that Maven's archetypes (or maybe it's the Eclipse plugin) are capable of configuring Eclipse's launcher configurations.

Woolworths in Australia (not the same as Woolworths in the US) is using this system. They've used ROO on 3 different projects, from simple to very complex projects. For the complex project, ROO had to add support for composite primary keys. Many of the issues ROO had with Dozer were fixed and contributed back to the project by Woolworth's developers.

My Thoughts
ROO looks like a pretty cool system. It reminds me a lot of Grails' GORM except that it requires more tooling. Ben said most of the code generation is driven by a Java class. I wonder if it has templates (i.e. FreeMarker) that can be modified? If ROO ever becomes an open source project, I'm guessing it will be very polished and well-received. I'm sure we could use ROO in AppFuse and make a lot of Java developers very happy.

Posted in Java at Dec 10 2006, 10:32:04 AM MST 19 Comments
Comments:

Does ROO have a site or some code hosted somewhere?

ROO does look like a very nice architecture. I have been moving toward a similar architecture but I still didn't figure out how to easily generate the DTOs. DTOs and the database test data are a major pain right now so I would be greatly interested to find out more about ROO.

Posted by Nadeem Bitar on December 10, 2006 at 09:22 PM MST #

"Ben just did a survey of the room asking who's using Ant vs. Maven. Surprisingly, Ant only slightly beats Ant." typo?

Posted by Wim Deblauwe on December 11, 2006 at 07:39 AM MST #

Hi Matt, thanks for your Spring Experience reports ;) I've read with great interest your latest two reports, in particular this one regarding Ben's talk, because I'm a great fan and contributor of the DDD community, and because I'm the author of the XT Framework (https://springmodules.dev.java.net/docs/reference/0.7/html_single/#xt). I'd like to know more of the ROO Framework prior to give a full opinion, but as a first impression I have to say that I like the idea of a Domain-centric approach, even if I don't like too much all that code generation, and that use of DTOs. Talking about the XT Modeling Framework, it is more oriented towards a set of facilities and patterns implementations to help you develop your business project and domain in a DDD-way: it is not the implementation of an architecture, like ROO seems to be. What points of contact between the two do you see? Cheers! Sergio B.

Posted by Sergio Bossa on December 11, 2006 at 03:26 PM MST #

Thank your for thoses very nice reports. Good job as usual :) I'm still confused with ROO, what are the difference with other similar projects like Grails, Rails, Symfony etc. What would make you decide to go for ROO instead of, say, humm Appfuse?

Posted by Sylvain Gogel on December 11, 2006 at 06:05 PM MST #

Wim - you are right, it was a typo. I've fixed it in the post. Thanks!

Posted by Matt Raible on December 11, 2006 at 06:40 PM MST #

Hi Matt,
The following paragraph:
"Since most of the code is in the middle-tier (including business), the middle-tier is ..."
I guess, should be
"Since most of the code is in the DO layer (including business), the middle-tier is ..."
In addition I see an indistinct use of layer and tier. In spanish there aren't two words for differentiating and some time is confuse use a single word for both terms.

Posted by David Solis on December 12, 2006 at 01:45 AM MST #

I've corrected the typo, thanks David.

Posted by Matt Raible on December 12, 2006 at 02:02 AM MST #

Hi Matt,

Thanks a lot for all the detailed reports on TSE. Regarding ROO, we have been using something similar in delivering projects for our clients. We have an in-house meta-framework (if I may use the word) named Infusion (http://www.anshinsoft.com/infusion), which can do many of the things which ROO does :-

a) eclipse plug-in for creating Infusion projects based on Maven 2
b) automatic generation of DTOs, through a Maven plugin (MOJO)
c) regarding the domain layer, we are thinking of integrating with an MDA framework like EMF or AndroMDA
d) out-of-the-box integration with Spring and Hibernate

Would love to get some more links and info about ROO.

Thanks. - Debasish

Posted by Debasish Ghosh on December 12, 2006 at 08:04 AM MST #

Dozer still presents us with issues which require workarounds, even after our patches, and our intention is to unplug it as ROO's DTO Assembler and write a new one. Using ROO in our project has dramatically cut down the amount of code we have had to write. Regards Alan, Woolworths Limited

Posted by Alan Stewart on December 12, 2006 at 09:34 AM MST #

Interesting, this looks a bit more "heavyweight" than what we normally see from the Spring team.

I thought that DTOs had officially become mosly an anti-pattern, but I guess this will spark up that debate once again. Also, it seems that other recent trends have steered away from code generation, and this is also leading us back in that direction.

One thing that I've always liked about the Spring camp is that they give you many different choices, but the framework and the general patterns and practices that it suggests tends to steer us in one general direction which is important in today's world where we have sooooo many choices and decisions to make.

Just my initial thoughts and observations, I'm certainly open to new ideas...

Posted by Mark Helmstetter on December 13, 2006 at 10:01 PM MST #

Hi Matt,I want to know Appfuse 2.0's Release Date?

Posted by aninggo on December 15, 2006 at 06:50 AM MST #

aninggo - we currently don't have a release date for 2.0. We are working on it though and hope to push out some sort of release in the next couple weeks. In the meantime, I'd suggest you use 1.9.4.

Posted by Matt Raible on December 18, 2006 at 09:23 PM MST #

It's exactly the same layering I was implementing. Done some posts on Spring and Andromda but no response.

If anynoe can have a look at my post and just tell me if I'm on the right or wrong way, I'll be most gratefull) :http://forum.springframework.org/showthread.php?t=31776

I was customizing appfuse to generate my own code, so I think I'll throw it away and have a look at RRO when it's available.

nota bene : it would be great if afterwards misters Evans and Fowler bless the ROO architecture (or another one) - so we (I?) 'll be perhaps a little less confused about java programming patterns - or just java coding - (see article and remarks on validation for instance http://blog.interface21.com/main/2006/08/25/validation-logic-and-my-first-post/ - we don't know how to validate data anymore what a pity :!).

Posted by gonzalad on December 18, 2006 at 10:51 PM MST #

Thanks,matt.I accept your suggestion !

Posted by aninggo on December 19, 2006 at 01:04 AM MST #

I believe the ROO architecture is very sound. Many people have reservations about the use of DTOs, but if one does not want to expose domain objects beyond the facade layer, I would like to know some (good) alternatives. Anyhow, ROO will auto-generate the DTO for you. I'm very impressed with the quality of the code base, and also have had the pleasure of contributing to ROO. Moreover, it has saved us a great deal of time in my current project. Ben's code auto-generates more than 350 Junit tests for the domain objects we have. However, the Assembler implementation (conversion between domain object and data transfer object) needs more attention, to keep the domain objects pure and once this has been addressed, ROO will, in my opinion, be bullet proof! Alan

Posted by Alan Stewart on December 23, 2006 at 11:52 AM MST #

First, ROO is nice and I think it is a reasonable solution when we think about a Enterprsie IT services. For those who think that the DTO can be generated, my opinion is that we cannot. The DTO are the parts of your system that you create to adapt your business objects to the different clients. DTOs are partials objects graphs that cannot be generated because there are context specific; if you try to describe theses contexts, you necessarily create the DTO !

Posted by Erik on December 27, 2006 at 02:59 PM MST #

ROO gives the developer the option to auto-generate the DTO or not and by default it will. In our application the majority of DTOs were generated and used in web controllers quite effectively. One example where we did not want a generated DTO was our UserDto object, that implemented Acegi's UserDetails interface. ROO is very configurable. Alan

Posted by Alan Stewart on December 31, 2006 at 12:18 AM MST #

As an update, Dozer 3.4 has solved all our mapping issues. With this version we can use private no-arg constructors in our domain objects, as Dozer (and Hibermate) can use reflection to instantiate classes. Alan

Posted by Alan Stewart on June 06, 2007 at 01:57 AM MDT #

[Trackback] Someone referenced this post to answer question "Confused about Constructors in Java?"...

Posted by Copious-Systems on December 01, 2010 at 07:51 PM MST #

Post a Comment:
  • HTML Syntax: Allowed