This is the first in series of articles about Object Relational Mapping.

Lately, I have seen many agile projects choosing code generation tools to implement a persistence mapping layer, using Hibernate as their ORM of choice.

In most cases, the relational schema has already been defined by the customer and the team is developing the backend system around it. This common scenario leads to the Bottom up approach for building the persistence layer in which the development begins from an existing database schema and data model.

One can see why it is hard to resist the temptation of using code generation tools to generate the Java persistence entities as well as the DAO layer. Many developers have chosen this approach believing they were following the XP mantra: “Do the Simplest Thing that could possibly work”.

“The simplest thing” is sometimes misinterpreted as “the quickest thing” since code generation is lot quicker then hand crafting code. In this article series, I will talk about the dangers of the reverse-engineering-code-generation approach, and look into how to apply the Simplest Thing without compromising the quality of the domain model.

The reverse mapping of a database schema into an Object Domain model is a nice idea but it is fundamentally flawed given the impedance mismatch between these two models.  It’s like trying to translate from one language to another using Yahoo Babel Fish. It can work if you have simple text, but as soon as you introduce more complexity in the language structure of the original text then things can get lost in translation or misinterpreted and in some cases the final result become completely bogus.  Same with these tools, it can work if the database schema is very simple.

The Paradigm Mismatch versus Code Generation Tools

Granularity

Perhaps the most pervasive problem is related to granularity, which refers to the relative size of types we deal with, to illustrate this problem consider the following Users table:

create table  USERS (
   USERNAME varchar(30) not null primary key,
   FIRSTNAME varchar(50) not null,
   LASTNAME  varchar(50) not null,
   STREET varchar(100),
   CITY varchar(100),
   STATE varchar(15),
   ZIPCODE varchar(10)
)

If we were to use the code generation tool (pick your favorite tool, it does not matter), from this schema the tool would generate the following java class:  (complete code omitted for simplicity)

@Entity
@Table(name = "USERS")
public class Users implements Serializable {

  private String city;
  private String userName;
  private String firstName;
  private String lastName;
  private String street;
  private String state;
  private String zipcode;

  ...
}

What is the problem with the above class?

The tool is doing a “literal” translation from the database schema into Java. Just because they choose to mix User information and Address information in the same SQL table, most likely to avoid table joins, that doesn’t mean the Java equivalent has to follow.  A much better mapping or translation would be:

@Entity
@Table(name = "USERS")
public class Users implements Serializable {

  private String userName;
  private String firstName;
  private String lastName;
  private Address address

  ....

}

In the above class, the Address type is being used to replace the scattered address attributes. By doing so we not only construct a semantically richer model, but we can now re-use the address concept elsewhere in the application. Here, the Address class is an example of a Value Object (See Domain Driven Design by Eric Evans).  The point here is that only the domain modeler has this kind of knowledge to construct a rich object model.

On the next segment, we will look into other aspects of the Paradigm Mismatch so that we can be better prepared to fix any translation issues when using the bottom up approach.

Permalink

This entry was posted on Friday, February 20th, 2009 at 6:05 pm and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.