Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Bridge the gap between Struts and Hibernate

Extend Struts for a more object-oriented relationship with Hibernate

By Ted He, JavaWorld.com, 03/06/06

In the book Hibernate in Action (Manning, October 2004), authors Christian Bauer and Gavin King reveal the paradigm mismatch between the two worlds of the object-oriented domain model and the relational database. Hibernate does an excellent job at the persistence layer of gluing these paradigms together; however, a mismatch remains between the domain model (the Model-View-Controller model layer) and HTML pages (the MVC view layer). In this article, we examine this mismatch and consider an approach for resolving the disparity.

The paradigm mismatch rediscovered

Let's look at a classic parent-child relationship example (illustrated in the code below): product and category. The Category class defines an identifier id of type Long and a property name of type String. The Product class also has an id of type Long as well as a property category of type Category, representing a many-to-one relationship with instances of the Category class (i.e., many Products can belong to one Category).

 /**
 * @hibernate.class table="CATEGORY"
 */ 
public class Category {
   private Long id;


   private String name;


   /**
    * @hibernate.id generator-class="native" column="CATEGORY_ID"
    */
   public Long getId() {
      return id;
   }


   public void setId(Long id) {
      this.id = id;
   }


   /**
    * @hibernate.property column="NAME"
    */
   public String getName() {
      return name;
   }


   public void setName(Long name) {
      this.name = name;
   }
}


/**
 * @hibernate.class table="PRODUCT"
 */
public class Product {
   private Long id;
   private Category category;


   /**
    * @hibernate.id generator-class="native" column="PRODUCT_ID"
    */
   public Long getId() {
      return id;
   }


   public void setId(Long id) {
      this.id = id;
   }


   /**
    * @hibernate.many-to-one
    * column="CATEGORY_ID"
    * class="Category"
    * cascade="none"
    * not-null="false"
    */
   public Category getCategory() {
      return category;
   }


   public void setCategory(Category category) {
      this.category = category;
   }
}

It is desirable that a product be re-categorized, so our HTML view provides a drop-down list of all categories to which products can be assigned:

 <select name="categoryId">
   <option value="">No Category</option>
   <option value="1">Category 1</option>
   <option value="2">Category 2</option>
   <option value="3">Category 3</option>
</select>

The categoryId field specifies the user selection of a Category. In Struts, we define ProductForm as an ActionForm subclass to collect the user's inputs from the HTTP request:

 public class ProductForm extends ActionForm {
    private Long id;
    private Long categoryId;
    ...
}

Here's the mismatch: in the Product domain object, the category property is of type Category, whereas the ProductForm only has a categoryId property of type Long. This mismatch not only increases inconsistency, but also involves special code for converting between primitive type identifiers and associated objects.

Part of this discrepancy is due to the HTML form itself: it resembles a relational model, instead of an object-oriented model. The object-oriented versus relational mismatch in the persistence layer is addressed by object-relational mapping (O/RM). The similar mismatches in the view layer still remain. The key is finding a solution to make them work together seamlessly.