Cómo modelar en Java EE?

Question

digamos Vamos, he decidido ir con la pila de Java EE para mi aplicación empresarial.

Ahora, para el modelado de dominio (o: para el diseño de la M del MVC)?, Que las API que pueden suponer con seguridad y uso, y que yo debería mantenerse alejado de ... digamos, a través de una capa de abstracción

Por ejemplo,

1. ¿Debo ir por delante y la basura mi modelo con llamadas a la API de Hibernate / JPA? O, ¿debería construir una abstracción ... una capa de persistencia de mi propia para evitar la codificación dura en contra de estas dos API específica de persistencia? ¿Por qué te pido esto: Hace pocos años, hubo esta API Kodo que consiguió reemplazado por Hibernate. Si uno se había diseñado una capa de persistencia y codificado el resto del modelo frente a esta capa (en lugar de tirar basura al modelo con llamadas a la API específica del proveedor), que habría permitido una a (relativamente) pasar fácilmente de Kodo a Hibernate a XYZ.

2. Es recomendable hacer uso agresivo de la QL * proporcionado por el proveedor de persistencia en el modelo de dominio? No estoy al tanto de cualquier problema del mundo real (como el rendimiento, la escalabilidad, portabilidad, etc.) que se deriven de un uso intensivo de un HQL-como el lenguaje. ¿Por qué te pido esto:. Me gustaría evitar, en lo posible, la escritura de código personalizado cuando el mismo se podría lograr a través de consulta en lenguaje que es más portátil que SQL

Lo siento, pero yo soy un completo novato a esta zona. ¿Dónde puedo encontrar más información sobre este tema?

Answer 1

Esto es lo que creo que es el punto de vista tradicional:

• Las entidades en su proyecto forman el modelo de dominio. Deben ser reutilizable y no estrechamente unida a una tecnología de persistencia (Voy a volver más tarde acerca de la articulación flexible frente apretada)
• La capa de negocio, utiliza el modelo de dominio, pero también expone los servicios y otras materias.
• La capa de acceso de datos se encarga de persistir el modelo de dominio (entidades) en un almacén persistente.

Una entidad no debe llamar a la capa de acceso a datos directamente. Sin embargo, la capa de negocio voluntad, de manera que la carga y persisten las entidades del modelo de dominio.

Si asigna a que las tecnologías Java EE que se suele sentir algo como:

• Entidades -> POJO con anotaciones de Hibernate / JPA. Tenga en cuenta que las anotaciones no implican una estrecha conexión con JPA / Hibernate, el mismo POJO podría ser utilizado en otro lugar sin Hibernate.
• capa de negocios -> Sesión EJB o primavera
• capa de acceso de datos -> JPA / Hibernate

Esto es un esbozo y hay una gran cantidad de variantes posibles. Puede saltar en particular la sesión EJB y aplicar la capa de negocio de otra manera. También puede decidir tener la llamada capa de negocio de la Session de Hibernate JPA / / EntityManager directamente, en cuyo caso JPA / Hibernate es realmente el DAL, o puede que desee para envolver acceder a la sesión / EntityManager en el llamado Data Access Objects (DAO ).

En cuanto a HQL, tratar de atenerse a lo que es portátil, y si se utiliza SQL nativo, siga SQL-92 convenciones. Si telas se complican, tal vez introducir DAOs. De esta manera, usted sabe que el único lugar donde hay consultas HQL está en los DAOs. También puede implementar por primera vez la lógica de consulta "de procedimiento" en el DAO, y si usted tiene un problema de rendimiento, vuelva a ponerla en práctica con una consulta HQL más complicado.

Editar

En cuanto a sus preguntas en el comentario:

La capa de negocio depende de la capa de datos. Si desea que la capa de negocio para no depender de Hibernate / JPA entonces su necesidad capa de datos a Extracto Hibernate / JPA de distancia. Si utiliza DAO para su capa de datos, que será el caso. La DAO será la "capa de persistencia delgada escritos a mano sobre Hibernate" (para tomar sus palabras). Me gustaría introducir DAO para todas las entidades en su caso.

Lo que su están pidiendo es una cuestión de diseño bastante genérico. No puedo dar una receta definitiva para eso, ni posiblemente resumir todas las variantes en una respuesta ya que depende de caso por caso. Por ejemplo, no hemos hablado hasta ahora sobre el problema de las transacciones, que suelen comenzar en la capa de negocio, pero que la capa de datos debe tener en cuenta. Esto suele depender de las tecnologías utilizadas y sus necesidades.

Sin embargo, aquí hay una lista de los recursos que le pueden interesar: los libros patrón de arquitectura de aplicación empresarial , el libro Patrones del mundo real de Java EE - Rethinking Buenas Prácticas , el libro Domain Driven Design y más específicamente los patrones de acceso a datos de objetos , Repositorio patrón , sesión abierta en vista (si es para una aplicación web ), Y tal vez modelo de dominio anémico.

EDIT 2

bien, un poco más frases sobretransacciones:

Las transacciones debe ser gestionado conceptualmente en la capa de negocio; la definición de lo que hay que hacer en una unidad de trabajo para ser coherente depende de hecho en la propia lógica de la aplicación.

Con EJB3, las transacciones puede ser declarada con anotaciones y la aplicación. servidor gestiona por usted. Ver este otro respuesta de la mina para más información. Con la primavera también se puede marcar las transacciones declarativa, pero no sé los detalles. O tendrá que volver a iniciar / detener la transacción usted mismo. Este será un poco diferente si se utiliza transacciones JDBC o transacciones JTA.

Transacciones se refiere también a la carga diferida en Hibernate / JPA. Una entidad que era perezoso cargado, de hecho puede ser cargado sólo si hay una transacción actual. Si las transacciones se termina en la capa de negocio, las entidades que se devuelven a la necesidad capa de presentación que se cargan con impaciencia.

Para evitar este problema, un modelo popular para aplicaciones web es sesión abierta en vista , que ya he mencionado. En este caso, la capa de presentación de inicio / parada de las transacciones (que es conceptualmente un poco mal), pero funciona muy bien con la carga diferida.

Answer 2

Su modelo de dominio y su capa de persistencia en teoría deberían estar separados - no hay necesidad de una clase llamada Entity saber nada acerca de si y cómo se conserva, por lo que podría utilizar algo como Hibernate para crear la capa de persistencia sin contaminar el clases del modelo de dominio propios. No lo hace "código de la [...] modelo frente a esta capa" - codificar el modelo, a continuación, asignar a un almacén 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 que está bien.

Yo personalmente luchar tímido de usar demasiado HQL con (N) Hibernate por la razón de preguntar, pero hay momentos en los que es inevitable. Usted ya sabe, y usted tiene resaltado, el principal problema que hay, por lo que es poco probable que el uso excesivo de todos modos.