Java EE 6 - Permanent Domain Object Template - Any Success?

Question

I have a rather complicated application using POJO and now it came to port it to EJB3.1 so that it can be deployed online, accessed through REST services and benefit from the container environment (persistence was the most important, but transactions would have been useful).

I have been out of Java EE since J2EE, and I am struggling to unravel the "loss" of the beans object. It took me a while to understand that Entities in EJB3.1 are not really Beans in the old sense ... :) I read several EJB3 books, including the O'Reilly Enterprise JavaBeans 3.1 User Guide, all of which explain concepts and EJB3 components, but not implementation template parameters.

In my research and research looking for Java EE 6 patterns, I rather took the approach of Adam Bien, especially the "Persistent Domain Objects" (PDO) pattern (in his book, but also briefly here: http://download.java.net/ general / podcasts / real_world_java_ee_patterns.pdf ), which seems to provide the least complexity and greatest synergy with my current POJO application. PDO is also closely associated with traditional object-oriented philosophies and approaches and really appeals to me.

Instead of answering the PDO debate, I'm interested in hearing from the people who implemented it and what worked against where you had difficulties. In particular, I would like to know how you made calls from JPA objects to other services in the container (for example, calls to a session without Beans state, etc.).

I would also be interested to know if there are alternatives to the PDO template that allow me to maintain the structure of the application (using polymorphism, etc.) without the need to create a bean session and JPA entity for each class in my model, (I do not want to do this partially due to the huge exercises needed to reorganize all unit tests and integration, and partly because, as far as I can tell, I will try to reproduce my relationship with 1toMany objects, etc. in my Beans session too, which seems crazy) .

Does anyone have any impressions to share, or if you want to point out that I'm an idiot and have missed something fundamental in Java EE 6, which will also be "welcome" :)

TIA

Answer 1

There are no answers, so maybe I'm the only one doing this;) For those looking for pointers, I found:

• Your object model needs serious modification. You cannot use Maps or Interface Lists, as in an application other than JPA, since JPA cannot "handle" you need to save (abstract) classes. Hibernate has the annotation @Any and @ManyToAny, but the overhead (performance, functionality, and coding) is significant (IMHO). If you can implement a hideous abstract class hierarchy, then you should. YUK!

• If you have an indefinitely complex object model (more than six relationships between objects), you will receive LOTS commands from JOIN in the SQL code generated by the JPA engine. I read somewhere that> 6 JOINS puts a big load on the database (just a sure rule). MySQL has a hard limit of 61 connections. Sounds insanely high, of course, you would never hit! If you have a hierarchy of abstract objects and several relationships between objects, which it will soon add!

I did not find a way around the first "problem". Feeling bad is using a lot of abstract base classes instead of interfaces, but this is inevitable, as far as I can tell. Please tell me if not!

The second problem can be solved using the lazy-fetch on object relationship or using the Adam Gateway template and extended duration sessions (instead of a session without saving the state of the beans load and saving the model with each call). So far I am going with the latter, but still have not reached the point that I can load the test for memory and database usage. We'll see!