Flujo de trabajo estándar cuando se trabaja con JPA

Question

Actualmente estoy tratando de entender bien el trabajo con JPA. No puedo evitar sentir que me estoy perdiendo algo o hacerlo de la manera incorrecta. Simplemente parece forzado hasta el momento.

Lo que creo que sé hasta ahora es que su son dos formas de trabajar con APP y herramientas para apoyar esto.

• se puede hacer todo en Java utilizando anotaciones, y dejar que la APP (sea cual sea la aplicación que decida usar) crear su esquema y actualizarlo cuando se realizan cambios.
• Puede utilizar una herramienta para realizar una ingeniería inversa de su base de datos y generar las clases de entidad para usted. Cuando se actualiza el esquema, debe regenerar estas clases o actualizarlas manualmente.

Parece haber inconvenientes para ambos y beneficios para ambos (como con todas las cosas). Mi pregunta es en una situación ideal ¿cuál es el flujo de trabajo estándar con JPA? La mayoría de los esquemas requerirán actualizaciones durante la fase de mantenimiento y especialmente durante la fase de desarrollo, entonces, ¿cómo se maneja esto?

Answer 1

No siempre es un buen enfoque generar el esquema DB de las entidades anotadas . Aunque en teoría suena genial, en la práctica a menudo el esquema generado no es óptimo y no satisfaría y experimentaría al DBA.

El enfoque que sigo en mi flujo de trabajo es crear las entidades y el esquema db por separado, mientras sigo usando una herramienta bastante inteligente para la creación de esquemas, ya sea como Liquibase, que es agnóstico de base de datos, soporta revisiones, retrocesos, etc. ... o una herramienta personalizada de migración horneada que simplemente ejecuta secuencias de comandos sql específicas db fuertemente optimizadas. Probablemente suene menos que ideal, pero puedo asegurar que hace los trabajos y mantiene el código relacionado con el esquema coherente, ya que Grigory señaló que no todo lo relacionado con la base de datos puede generarse de las entidades de todos modos.

Puedo, sin embargo, ser útil para generar el esquema de las entidades de la base de datos de prueba contra la que las pruebas de unidad e integración están en ejecución. Suponiendo que está utilizando, por ejemplo, PostgreSQL es producción, puede decidir acelerar las pruebas de unidad que ejecutan alguna base de datos incorporada en memoria como H2 que se crea a partir de las entidades antes de que se inicien las pruebas y desaparece automáticamente (ya que estaba en memoria) después de que las pruebas terminen de ejecutarse. Esta es una práctica muy común.

Answer 2

Como de costumbre la respuesta es que depende ...

enfoque ideal (en el mundo ideal) probablemente sería su primera opción: mantener todo utilizando anotaciones JPA y artefactos de bases de datos utilizando el ingeniero adelante herramienta de utilidad (por ejemplo, utilizar Hibernate Maven plugin) .

Depende del nivel de apoyo para sus artefactos de bases de datos - no todo es de una o adecuado para anotaciones. Es por eso que mis proyectos usualmente usan mantenimiento paralelo para ambos y usan pruebas unitarias para mantenerlos sincronizados.

También depende de los recursos disponibles. Si tiene un DBA dedicado que es responsable de su base de datos, entonces delegarle el mantenimiento tendría sentido.

Otra consideración es cuánto desarrollo de base de datos se hace realmente en JPA. ¿Hay también procedimientos almacenados u otras aplicaciones que no son JPA que usan el mismo back-end, o tal vez solo se integra con la base de datos de otro equipo?

Answer 3

Si esta es una aplicación existente, comprobaría lo que tiene, si la estructura de la base de datos compleja que se ve con DDL y DDL muestra que se está haciendo una lógica significativa en la base de datos, entonces estará mejor utilizando SQL simples y deje que el DBA mantenga sus estructuras de datos. JPA en realidad no presta bien cuando las estructuras de la base de datos ya son complicadas y no hay beneficio comercial para usar JPA en ese punto.

Lo que debe suceder es un proyecto para migrar a JPA. Hay algunas ventajas:

• La lógica de negocios se elimina de la capa de la base de datos (que es más difícil de escalar horizontalmente) al nivel de la aplicación.
• Los desarrolladores de Java son generalmente más baratos en comparación con un DBA. Aunque todavía necesitas a alguien que pueda hacer tanto el pensamiento de base de datos como el pensamiento de Java para hacer esto correctamente y eso es más raro.
• Al reducir la base de datos para que se convierta en un almacén de datos simple, puede liberarse del bloqueo de proveedor.
• Si lo hace bien, puede tener una base de datos diferente para el desarrollo (puede ser DB2 Express C, que es gratis) y tener una base de datos más sólida para sus entornos de integración y producción (por ejemplo, DB/2 para zOS). Esto le permite tener más desarrolladores sin preocuparse tanto por los costos de las licencias.

En cuanto a los esquemas que se generan y tal, en realidad hay cuatro flujos de trabajo que pueden ocurrir:

1. Por diseño, un objeto-relacionales (en lugar de una Entidad-relacional) diagrama sirve como un contrato entre el equipo de aplicación y el equipo de la base de datos. El resultado final es que los objetos JPA se ejecutarán en la estructura de datos físicos que establece el DBA.
2. Para el desarrollo de aplicaciones Java, simplemente deje que cada desarrollador tenga su propia base de datos y permita que exploten todo lo que deseen. El código JPA generará los esquemas para usted.
3. Para el desarrollo de la base de datos, los esquemas generados y los diagramas de clases son pasados ​​a revisión por el DBA para ver dónde se puede mejorar el rendimiento. Específicamente están allí para especificar los índices que no están disponibles en el estándar JPA ya que no es una base de datos cruzada. También están ahí para configurar los espacios de tablas y todos los controles de acceso y esquemas para el desarrollo, pero al menos la esencia de la estructura puede ser eliminada de ellos y pasada al equipo de aplicaciones, lo que le da al equipo de aplicaciones más flexibilidad para adaptarse a los cambios Lo que normalmente sucedería es que el DBA solo incluye algunos SQL generados y luego tiene alteraciones para agregar columnas adicionales y otras que se usarían para otros fines fuera de la aplicación (la estructura de JPA solo necesita lo que necesita la aplicación, no necesita para mapear uno a uno al 100% a la base de datos)
4. Para la migración, el DBA necesita hacer un análisis diferencial entre los dos esquemas. Hay un programa llamado dbsolo (no gratuito) que puede hacerlo con la mayoría de las bases de datos. Sin embargo, si las cosas se hicieron en JPA, las estructuras son más simples ya que en teoría ya no existe ninguna lógica comercial en la base de datos, lo que reduce la complejidad de las migraciones de datos debido a las actualizaciones.

No se puede decir que está utilizando JPA sin involucrar a todo el equipo de entrega, que deberá incluir al DBA dispuesto a ceder el control y la propiedad de la estructura de los datos a la aplicación equipo, pero aún así ser parte del diseño y las revisiones.