Java EE 6 - The Persistent Domain Objects pattern - any successes?

Question

I have a moderately complex application using POJOs, and now come to migrated it to EJB3.1 so it can be deployed online, accessed through REST services and benefit from the container environment (persistence being the most major, but transactions would be useful too).

I have been away from Java EE since the J2EE days, and am struggling to get my head around the "loss" of entity beans. It took me a while to realise that Entities in EJB3.1 are not actually Beans in the old sense... :) I have read a number of EJB3 books including the O'Reilly Enterprise JavaBeans 3.1 "manual", all of which explain the concepts and components of EJB3 but not the implementation pattern options.

In my research and investigation looking for Java EE 6 patterns I'm rather taken by Adam Bien's approach - particularly the "Persistent Domain Objects" (PDO) pattern (in his book but summarised here too: http://download.java.net/general/podcasts/real_world_java_ee_patterns.pdf), which appears to offer the least complexity and most synergy with my current POJO app. PDO also closely-aligns with the traditional Object Oriented philosophies and approach, and really appeals to me.

Rather than resparking a debate over PDO, I'm interested to hear from people that have implemented it and what worked vs. where you had difficulties. In particular I'd like to find out how you made calls from JPA entities out into other services in the container (like calls to stateless session beans etc).

I'd also love to know if there are alternatives to the PDO pattern that allow me to maintain the application structure (using polymorphism etc) without having to create a session bean and a JPA entity for every class in my model. (I don't want to do that partly because of the massive exercise required to refactor all of the unit and integration tests, and partly because - as far as I can see - I'll end up trying to replicate my 1toMany etc object relationship across my session beans too which seems crazy).

Does anyone have any experiences to share - or if you'd like to point out I'm an idiot and have missed something fundamental in Java EE 6 that would be "welcome" too :)

TIA

Answer 1

No replies so maybe I'm the only one doing it ;) For anyone else looking for pointers, I have found:

• your object model needs major modification. You can't use Maps or Lists of interfaces as you would in a non-JPA app, because JPA can't "handle" interfaces, you need to persist (abstract) classes. Hibernate has an @Any and @ManyToAny annotation, but the overhead (performance, functionality and coding) is (IMHO) significant. If you can implement a hideous abstract class hierarchy then you should. YUK!

• If you have a vaguely complex object model (more than six relationships between objects) you will end up with LOTS of JOIN commands in the SQL code that is generated by the JPA engine. I read somewhere that >6 JOINS puts a high load on the database (just a rule-of-thumb I'm sure). MySQL has a hard limit of 61 joins. Sounds crazily high, surely you'd never hit that?! If you've got an abstract object hierarchy and a few relationships between objects it soon adds up!

I haven't found a way to get around the first "problem". It feels wrong to ram-in lots of abstract base classes instead of interfaces, but it's unavoidable as far as I can see. Please tell me if not!

The second problem can be managed by using lazy-fetch on object relationships, or by using Adam's Gateway pattern and extended persistence sessions (rather than stateless session beans loading and saving the model on every call). I'm going with the latter so far - but haven't got to a point where I can load-test on the memory and database usage yet. We'll see!