¿Cuándo se puede/debe hacer todo lo posible con el enfoque ORM?

Question

Me parece que se supone que la introducción de una herramienta ORM hace que su arquitectura sea más limpia, pero por razones de eficiencia, me he encontrado omitiendola e iterando sobre un conjunto de resultados JDBC en ocasiones.Esto conduce a una maraña descoordinada de artefactos en lugar de una arquitectura más limpia.

¿Esto se debe a que estoy aplicando la herramienta en un contexto no válido o es más profundo que eso?

¿Cuándo se puede/debe hacer todo lo posible con el enfoque ORM?

Cualquier idea sería muy apreciada.

---

Un poco de trasfondo:

En mi entorno tengo alrededor de 50 computadoras cliente y 1 servidor SQL razonablemente potente.

Tengo una aplicación de escritorio en la que los 50 clientes acceden a los datos en todo momento.

El modelo de datos del proyecto ha pasado por una serie de reorganizaciones por diversos motivos, entre ellos claridad, eficiencia, etc.

Historial de mi modelo de datos

1. JDBC llama directamente
2. DAO + POJO sin relaciones entre Pojos (básicamente envolviendo el JDBC).
3. Se agregaron relaciones entre POJO que implementan Lazy Loading, pero solo ocultan las llamadas entre DAO.
4. Se subió al tren de Hibernate después de ver lo "simple" que hacía el acceso a los datos (hacía que las relaciones entre POJO fueran triviales) y porque podía disminuir el número de viajes de ida y vuelta a la base de datos cuando se trabajaba con muchas entidades relacionadas.
5. Dado que era una aplicación de escritorio, mantener las sesiones abiertas a largo plazo era una pesadilla, por lo que terminó causando muchos problemas.
6. Retrocedí a un enfoque parcial de DAO/Hibernate que me permite realizar llamadas JDBC directas detrás de la cortina de DAO mientras al mismo tiempo uso Hibernate.

Answer 1

Hibernar tiene más sentido cuando su aplicación funciona gráficos de objetos, que persisten en el RDBMS.En cambio, si la lógica de su aplicación funciona en una matriz de datos 2-D, recuperarlos a través de JDBC directo funciona mejor.Aunque Hibernate está escrito sobre JDBC, tiene capacidades que podrían no ser triviales de implementar en JDBC.Por ejemplo:

1. Digamos que el usuario ve una fila en la interfaz de usuario y cambia algunos de los valores y desea activar una consulta de actualización solo para aquellas columnas que realmente cambiaron.
2. Para evitar llegar a un punto muerto, es necesario mantener un orden global para los SQL en una transacción.Obtener este JDBC correcto puede no ser fácil
3. Configurar fácilmente el bloqueo optimista.Cuando utiliza JDBC, debe recordar tener esto en cada consulta de actualización.
4. Las actualizaciones por lotes, la materialización diferida de colecciones, etc., también pueden ser no triviales de implementar en JDBC.

(Yo digo "podría no sea trivial", porque por supuesto se puede hacer - y podrías ser un súper hacker :)

Hibernate también le permite ejecutar sus propias consultas SQL, en caso de que sea necesario.

Espero que esto te ayude a decidir.

PD:Mantener la sesión abierta en un cliente de escritorio remoto y tener problemas en realidad no es un problema de Hibernate; se encontraría con el mismo problema si mantiene abierta la conexión a la base de datos por mucho tiempo.