Java EE 6 - El patrón Persistent Domain Objects - ¿algún éxito?

Question

Tengo una aplicación moderadamente compleja que usa POJOs, y ahora migro a EJB3.1 para que pueda implementarse en línea, acceder a través de servicios REST y beneficiarse del entorno contenedor (la persistencia es la más importante, pero las transacciones serían útiles también).

He estado alejado de Java EE desde los días J2EE, y estoy luchando para entender la "pérdida" de beans de entidad. Me tomó un tiempo darme cuenta de que las Entidades en EJB3.1 no son realmente Frijoles en el antiguo sentido ... :) He leído varios libros EJB3, incluido el "manual" O'Reilly Enterprise JavaBeans 3.1, todos los cuales explican los conceptos y componentes de EJB3 pero no las opciones de patrones de implementación.

En mi investigación e investigación en busca de patrones de Java EE 6 estoy más bien adoptado por el enfoque de Adam Bien, particularmente el patrón "Objetos de dominio persistentes" (PDO) (en su libro pero resumido aquí: http://download.java.net/general/podcasts/real_world_java_ee_patterns.pdf), que aparece para ofrecer la menor complejidad y la mayor sinergia con mi aplicación POJO actual. PDO también se alinea estrechamente con las filosofías y el enfoque tradicional orientado a objetos, y realmente me atrae.

En lugar de reavivar un debate sobre el PDO, me interesa saber de las personas que lo han implementado y de lo que funcionó frente a dónde usted tuvo dificultades. En particular, me gustaría saber cómo hizo las llamadas desde entidades JPA a otros servicios en el contenedor (como llamadas a beans de sesión sin estado, etc.).

También me gustaría saber si hay alternativas al patrón PDO que me permitan mantener la estructura de la aplicación (usando polimorfismo, etc.) sin tener que crear un bean de sesión y una entidad JPA para cada clase en mi modelo. (No quiero hacer eso en parte debido al ejercicio masivo requerido para refactorizar todas las pruebas de unidad e integración, y en parte porque, por lo que puedo ver, terminaré tratando de replicar mi relación de objeto 1toMany etc. a través de mis beans de sesión también que parece loco).

¿Alguien tiene alguna experiencia para compartir - o si desea señalar que soy un idiota y haber perdido algo fundamental en Java EE 6 que sería "bienvenida" también :)

TIA

Answer 1

No hay mas así que quizá soy el único que lo hace;) para cualquier otra persona en busca de punteros, que he encontrado:

• su modelo de objeto necesita una modificación importante. No puede usar Maps o Listas de interfaces como lo haría en una aplicación que no es JPA, porque JPA no puede interfaces "manejar", necesita persistir (abstraer) las clases. Hibernate tiene una anotación @Any y @ManyToAny, pero la sobrecarga (rendimiento, funcionalidad y codificación) es (IMHO) significativa. Si puede implementar una jerarquía de clase abstracta horrible, entonces debería. YUK!

• Si tiene un modelo de objeto vagamente complejo (más de seis relaciones entre objetos) terminará con MUCHOS de comandos JOIN en el código SQL generado por el motor JPA. Leí en algún lugar que> 6 JOINS pone una gran carga en la base de datos (solo una regla empírica, estoy seguro). MySQL tiene un límite de 61 uniones. Suena locamente alto, seguramente nunca golpearías eso? Si tienes una jerarquía de objetos abstractos y algunas relaciones entre objetos, ¡pronto se suma!

No he encontrado una manera de evitar el primer "problema".Se siente mal ramificar muchas clases base abstractas en lugar de interfaces, pero es inevitable por lo que puedo ver. Por favor dime si no!

El segundo problema se puede gestionar utilizando relaciones de objetos vagos o utilizando el patrón Adán Gateway y las sesiones de persistencia extendida (en lugar de beans de sesión sin estado cargando y guardando el modelo en cada llamada). Me voy con lo último hasta ahora, pero aún no llegué a un punto en el que pueda realizar pruebas de carga en la memoria y el uso de la base de datos. ¡Ya veremos!