java-ee - para - java j2ee

Cómo modelar en Java EE?

Question

Digamos que he decidido ir con Java EE stack para mi aplicación empresarial.

Ahora, para el modelado de dominios (o: para diseñar el M de MVC), ¿qué API puedo suponer y usar de forma segura, y de la que debería evitar ... digamos, a través de una capa de abstracción?

Por ejemplo,

1. ¿Debo continuar y dejar mi Modelo con llamadas a Hibernate / JPA API? O bien, ¿debería crear una abstracción ... una capa de persistencia propia para evitar una codificación dura contra estas dos API de persistencia específica? Por qué le pregunto esto: hace algunos años, existía esta API de Kodo que Hibernate reemplazó. Si uno hubiera diseñado una capa de persistencia y codificado el resto del modelo contra esta capa (en lugar de ensuciar el Modelo con llamadas a una API de proveedor específica), le habría permitido cambiar (relativamente) fácilmente de Kodo a Hibernar a xyz.

2. ¿Se recomienda hacer un uso agresivo del * QL proporcionado por su proveedor de persistencia en su modelo de dominio? No conozco ningún problema del mundo real (como el rendimiento, la escalabilidad, la portabilidad, etc.) que surja de un uso intensivo de un lenguaje similar a HQL. Por qué le pregunto esto: me gustaría evitar, en la medida de lo posible, escribir código personalizado cuando lo mismo podría lograrse a través del lenguaje de consulta que es más portátil que SQL.

Lo siento, pero soy un novato completo en esta área. ¿Dónde podría encontrar más información sobre este tema?

Answer 1

Su modelo de dominio y su capa de persistencia deberían estar separados en teoría: no es necesario que una clase llamada Entity sepa nada sobre cómo y cuándo persiste, por lo que podría usar algo como Hibernate para crear la capa de persistencia sin contaminar las clases de modelo de dominio. sí mismos. No "codifica el modelo [...] contra esta capa": codifica el modelo y luego lo asigna a una tienda persistente con algún tipo de capa ORM, donde el modelo de dominio no depende de la capa ORM. Obviamente, la capa de persistencia dependerá del modelo de dominio, pero está bien.

Personalmente lucho por usar demasiado HQL con (N) Hibernate por la razón que usted pregunta, pero hay veces en que es inevitable. Usted ya sabe, y usted mismo ha resaltado, el problema principal allí, por lo que es poco probable que lo use en exceso de todos modos.

Answer 2

Aquí está lo que creo que es la visión tradicional:

• Las entidades en su proyecto forman el modelo de dominio. Deben ser reutilizables y no estar estrechamente conectados a una tecnología de persistencia (volveré más adelante sobre el acoplamiento apretado contra el flojo)
• La capa de negocios utiliza el modelo de dominio, pero también expone servicios y otras cosas.
• La capa de acceso a datos se encarga de mantener el modelo de dominio (entidades) en una tienda persistente.

Una entidad no debe llamar a la capa de acceso a datos directamente. Pero la capa de negocios, de alguna manera, cargará y persistirá entidades del modelo de dominio.

Si asigna eso a tecnologías Java EE, generalmente obtiene algo como:

• Entidades -> POJO con anotaciones de Hibernate / JPA. Tenga en cuenta que las anotaciones no implican un acoplamiento estrecho con JPA / Hibernate, el mismo POJO podría usarse en otro lugar sin Hibernate.
• Capa empresarial -> Session EJB o Spring
• Capa de acceso a datos -> JPA / Hibernate

Es un esbozo y hay muchas variantes posibles. En particular, puede omitir el EJB de sesión e implementar la capa empresarial de otra manera. También puede decidir que la capa empresarial llame directamente a la sesión JPA / Hibernate / EntityManager, en cuyo caso JPA / Hibernate es realmente el DAL, o puede desear ajustar el acceso a Session / EntityManager en los llamados Objetos de acceso a datos (DAO )

Con respecto a HQL, trate de atenerse a lo que es portátil, y si usa SQL nativo, siga las convenciones de SQL-92. Si las cosas se complican, tal vez introduzca DAO. De esta forma, usted sabe que el único lugar donde hay consultas HQL es en los DAO. También puede implementar primero la lógica de consulta "procedurally" en el DAO, y si tiene un problema de rendimiento, vuelva a implementarlo con una consulta HQL más complicada.

EDITAR

En cuanto a tus preguntas en el comentario:

La capa de negocios depende de la capa de datos. Si desea que la capa empresarial no dependa de Hibernate / JPA, entonces su capa de datos debe abstraer Hibernate / JPA. Si usa DAO para su capa de datos, ese será el caso. El DAO será la "fina capa de persistencia escrita a mano sobre Hibernate" (para tomar sus palabras). Presentaría DAO para todas las entidades en su caso.

Lo que estás preguntando es una pregunta de diseño bastante genérica. No puedo dar una receta definitiva para eso, ni tampoco puedo resumir todas las variantes en una respuesta, ya que depende de cada caso. Por ejemplo, no hablamos tanto sobre el problema de las transacciones, que normalmente comienza en la capa de negocios, pero que la capa de datos debe tener en cuenta. Esto generalmente depende de las tecnologías utilizadas y sus requisitos.

Aún así, aquí hay una lista de recursos que podrían interesarle: los libros Patrón de arquitectura de aplicaciones empresariales , el libro Patrones de EE. UU. De Java del mundo real: Repensar mejores prácticas , el libro Diseño impulsado por dominio y más específicamente los patrones Objeto de acceso a datos , Repositorio patrón , Abrir sesión en vista (si es para una aplicación web) y tal vez Modelo de dominio anémico .

EDIT 2

Ok, algunas oraciones más sobre transacciones:

Las transacciones deben ser manejadas conceptualmente en la capa de negocios; la definición de lo que debe hacerse en una unidad de trabajo para ser coherente depende, de hecho, de la propia lógica de la aplicación.

Con EJB3, las transacciones se pueden declarar con anotaciones y la aplicación. el servidor lo hace por ti. Vea esta otra respuesta mía para más información. Con Spring también puede marcar las transacciones de forma declarativa, pero no sé los detalles. De lo contrario, tendrá que iniciar / detener la transacción usted mismo. Esto será ligeramente diferente si usa transacciones JDBC o transacciones JTA.

Las transacciones también se relacionan con la carga diferida en Hibernate / JPA. Una entidad que se cargó de forma diferida, de hecho, solo se puede cargar si hay una transacción actual. Si las transacciones finalizan en la capa empresarial, las entidades que se devuelven a la capa de presentación deben cargarse con entusiasmo.

Para evitar este problema, un patrón popular para aplicaciones web es Open Session in View , que ya mencioné. En este caso, la capa de presentación inicia / detiene las transacciones (lo cual es un poco erróneo conceptualmente), pero funciona bien con la carga diferida.