puts Blog.new(”nonsense”)

« Slides from Northern Virginia Java Users Group Presentation
First International Grails eXchange is Underway »

EJB3 Domain Classes Presentation at Grails eXchange: Slides, Sample Code, & Rampant Agnosticism

Posted by Jason Rudolph on October 15th, 2007

As an extension to last year’s Grails + EJB3 tutorial on InfoQ.com, I had the pleasure today of presenting an updated demo on this topic, showing just how easy it is to pimp out your EJB3 entity beans to include all the slick dynamic goodness we’ve come to know and love from traditional Grails domain classes.

Groovy Duke - Pimp Extraordinaire

But as much as I enjoy infusing boring, statically-typed EJB3 POJOs with GORM-powered productivity, I’m recently finding myself more excited about the ability to implement your Grails domain classes with any technology you like, and then simply expecting it all to just work. The result? Implementation-agnostic domain classes and the flexibility to use whichever technology is best suited for the task at hand. We’re free to choose…

Traditional Grails domain classes

  1. class Castle {
  2.     String name
  3.     String country
  4.  
  5.     static belongsTo = [Knight]
  6.  
  7.     Knight knight
  8. }

EJB3 entity beans (i.e., JPA-annotated POJOs)

(Some of the noise has been omitted here for sanity’s sake. Please feel free to download the sample code for the full experience.)

  1. @Entity
  2. @Table(name="knights")
  3. public class Knight implements java.io.Serializable {
  4.  
  5.   private long id;
  6.   private String name;
  7.   private long numDragonsSlain;
  8.   private Set<Sword> swords = new HashSet<Sword>(0);
  9.  
  10.   public Knight() {
  11.   }
  12.  
  13.   // …
  14.   @Id
  15.   @Column(name="knight_id", nullable=false)
  16.   public long getId() {
  17.       return this.id;
  18.   }
  19.  
  20.   public void setId(long id) {
  21.       this.id = id;
  22.   }
  23.  
  24.   // …
  25.  
  26.   @OneToMany(fetch=FetchType.LAZY, mappedBy="knight")
  27.   public Set<Sword> getSwords() {
  28.       return this.swords;
  29.   }
  30.  
  31.   public void setSwords(Set<Sword> swords) {
  32.       this.swords = swords;
  33.   }          
  34. }

JPA-annotated Groovy classes (i.e., POGOs)

  1. @Entity
  2. @Table(name="sword_inventory")
  3. public class Sword implements java.io.Serializable {
  4.  
  5.     @Id
  6.     @Column(name="serial_number", nullable=false, length=12)
  7.     String serialNumber
  8.  
  9.     @ManyToOne(fetch=FetchType.LAZY)
  10.     @JoinColumn(name="assignee")
  11.     Knight knight
  12.  
  13.     @Column(name="manufacturer", nullable=false)
  14.     String manufacturer
  15. }

Agnosticism Runneth Amuck

And regardless of the technology we choose for one domain class, we’re still free to implement the other classes however we like. The relationships remain intact, and GORM makes sure that it all just works. Using the classes above, we can walk the relationships navigating from one implementation technology … to another … to yet another still.

  1. groovy> def c = Castle.get(1)
  2. groovy> println "In the castle of ${c.name}, you can see ${c.knight.name} wield his mighty collection of ${c.knight.swords.size()} swords."
  3. groovy> go
  4. In the castle of Camelot, you can see King Arthur wield his mighty collection of 7 swords.

 
Cool! Use the implementation most appropriate for your needs, and let the framework figure out the rest.

–

Download the slides

Download the sample code

Print This Post Print This Post

This entry was posted on Monday, October 15th, 2007 at 3:07 pm and is tagged with with , . You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.

2 Responses to “EJB3 Domain Classes Presentation at Grails eXchange: Slides, Sample Code, & Rampant Agnosticism”

  1. peter Says:
    October 20th, 2007 at 9:46 am

    If you would add semicolumns to your ‘pogo’ class it would be a valid EJB3 entity by; since entities can be used with fieldlevel annotations / access. I hope these annotations are not going to be mandatory; otherwise I’d rather stick with Gorm as it is!

  2. BummerHan Says:
    November 7th, 2007 at 2:57 am

    Its an improvement to existing EJB3 developers to become groovier, can’t say its an improvement to just using GORM (Sun will never get this right sigh)

« Slides from Northern Virginia Java Users Group Presentation
First International Grails eXchange is Underway »