relacional - ¿Qué Java ORM prefieres y por qué?

orm ventajas y desventajas (10)

Es una pregunta bastante abierta. Comenzaré un nuevo proyecto y analizaré diferentes ORM para integrarlos con el acceso a la base de datos.

¿Tienes algún favorito? ¿Hay alguna que aconsejaría mantenerse alejado de?

He dejado de usar ORMs.

La razón no es ningún gran defecto en el concepto. Hibernate funciona bien. En cambio, he encontrado que las consultas tienen una sobrecarga baja y puedo encajar mucha lógica compleja en consultas grandes de SQL, y transferir gran parte de mi procesamiento a la base de datos.

Entonces considere usar el paquete JDBC.

Hibernate, porque es básicamente el estándar de facto en Java y fue uno de los motores en la creación de la APP. Tiene un excelente soporte en Spring, y casi todos los framework Java lo soportan. Por último, GORM es una envoltura realmente genial a su alrededor que hace buscadores dinámicos y así sucesivamente utilizando Groovy.

Incluso se ha portado a .NET (NHibernate) para que pueda usarlo allí también.

Hibernate, porque:

es estable, está presente por tantos años, carece de problemas importantes
Dicta las normas en el campo ORM.
Implementa el estándar (JPA), además de dictarlo.
tiene toneladas de información al respecto en internet. Hay muchos tutoriales, soluciones de problemas comunes, etc.
es potente: puede traducir un modelo de objeto muy complejo en un modelo relacional.
Tiene soporte para cualquier RDBMS mayor y medio.
Es fácil trabajar con él, una vez que lo aprendes bien

Algunos puntos sobre por qué (y cuándo) usar ORM:

trabaja con objetos en su sistema (si su sistema ha sido bien diseñado). Incluso si usa JDBC, terminará haciendo una capa de traducción, de modo que transfiera sus datos a sus objetos. Pero mis apuestas son que la hibernación es mejor en la traducción que cualquier solución personalizada.
no te priva de control. Puede controlar las cosas en detalles muy pequeños, y si la API no tiene alguna característica remota, ejecute una consulta nativa y usted la tiene.
cualquier sistema de tamaño mediano o más grande no puede permitirse tener una tonelada de consultas (ya sea en un lugar o dispersas), si pretende ser mantenible
Si el rendimiento no es crítico. Hibernate agrega sobrecarga de rendimiento, que en algunos casos no se puede ignorar.

Muchos ORM son geniales, necesita saber por qué desea agregar abstracción a JDBC. Puedo recomendarte http://www.jooq.org (descargo de responsabilidad: soy el creador de jOOQ, por lo que esta respuesta es parcial). jOOQ abarca el siguiente paradigma:

SQL es una buena cosa Muchas cosas se pueden expresar muy bien en SQL. No hay necesidad de una abstracción completa de SQL.
El modelo de datos relacionales es algo bueno. Ha demostrado ser el mejor modelo de datos de los últimos 40 años. No hay necesidad de bases de datos XML o modelos de datos verdaderamente orientados a objetos. En su lugar, su empresa ejecuta varias instancias de Oracle, MySQL, MSSQL, DB2 o cualquier otro RDBMS.
SQL tiene una estructura y sintaxis. No debe expresarse mediante la concatenación de cadenas de "bajo nivel" en JDBC o la concatenación de cadenas de "alto nivel" en HQL, ya que ambas son propensas a contener errores de sintaxis.
El enlace variable tiende a ser muy complejo cuando se trata de consultas importantes. Eso es algo que debe ser abstraído.
Los POJO son excelentes cuando se escribe código Java manipulando datos de base de datos.
Los POJO son un dolor para escribir y mantener manualmente. La generación de código es el camino a seguir. Tendrá consultas seguras para la compilación, incluida la seguridad del tipo de datos.
La base de datos es lo primero. Si bien la aplicación en la parte superior de su base de datos puede cambiar con el tiempo, la base de datos probablemente durará más.
Sí, tiene procedimientos almacenados y tipos definidos por el usuario (UDT) en su base de datos heredada. Su herramienta de base de datos debería soportar eso.

Hay muchos otros buenos ORM. Especialmente Hibernate o iBATIS tienen una gran comunidad. Pero si está buscando uno intuitivo y simple, le diré que pruebe jOOQ. ¡Te encantará! :-)

Echa un vistazo a este ejemplo de SQL:

// Select authors with books that are sold out SELECT * FROM T_AUTHOR a WHERE EXISTS (SELECT 1 FROM T_BOOK WHERE T_BOOK.STATUS = ''SOLD OUT'' AND T_BOOK.AUTHOR_ID = a.ID);

Y cómo se puede expresar en jOOQ:

// Alias the author table TAuthor a = T_AUTHOR.as("a"); // Use the aliased table in the select statement create.selectFrom(a) .whereExists(create.selectOne() .from(T_BOOK) .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT) .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

Ninguna, porque tener un ORM le quita demasiado control con pequeños beneficios. Los ahorros de tiempo obtenidos se pierden fácilmente cuando tiene que depurar anomalías resultantes del uso del ORM. Además, los ORM desalientan a los desarrolladores de aprender SQL y cómo funcionan las bases de datos relacionales y utilizar esto para su beneficio.

Si bien comparto las preocupaciones con respecto a los reemplazos de Java para consultas SQL de forma libre, realmente creo que la gente que critica a ORM lo está haciendo debido a un diseño de aplicaciones generalmente deficiente.

La verdadera OOD está dirigida por clases y relaciones, y ORM le brinda un mapeo consistente de diferentes tipos de relaciones y objetos. Si usa una herramienta ORM y termina de codificar expresiones de consulta en cualquier lenguaje de consulta que admita el marco de ORM (incluidos, entre otros, árboles de expresiones Java, métodos de consulta, OQL, etc.), definitivamente está haciendo algo mal, es decir, su modelo de clase. lo más probable es que no sea compatible con sus requisitos de la manera que debería. Un diseño de aplicación limpio realmente no necesita consultas en el nivel de la aplicación. He estado refactorizando muchos proyectos. La gente comenzó a usar un marco ORM de la misma forma en que estaban acostumbrados a incrustar constantes de cadenas SQL en su código, y al final, todos se sorprendieron de lo simple y fácil que se puede lograr con toda la aplicación. sube tu modelo de clase con el modelo de uso. Por supuesto, para cosas como la funcionalidad de búsqueda, etc., necesita un lenguaje de consulta, pero incluso entonces las consultas están tan limitadas que la creación de una VISTA y un mapeo incluso complejos que a una clase persistente de solo lectura es mucho más fácil de mantener y mirar que construir expresiones En algún lenguaje de consulta en el código de su aplicación. El enfoque VIEW también aprovecha las capacidades de la base de datos y, a través de la materialización, puede ser mucho mejor en cuanto al rendimiento que cualquier SQL escrito a mano en su fuente Java. Por lo tanto, no veo ninguna razón para que una aplicación no trivial NO use ORM.

Tuve una muy buena experiencia con Avaje Ebean cuando estaba escribiendo una aplicación JavaSE de tamaño mediano.

Utiliza las anotaciones JPA estándar para definir entidades, pero expone una API mucho más simple (No EntityManager o cualquiera de esas entidades adjuntas / separadas, basura). También le permite utilizar fácilmente consultas SQL o llamadas JDBC planas de eventos cuando sea necesario.

También tiene una API muy segura y segura para las consultas. Puedes escribir cosas como:

List<Person> boys = Ebean.find(Person.class) .where() .eq("gender", "M") .le("age", 18) .orderBy("firstName") .findList();

Yo recomendaría usar MyBatis . Es una capa delgada en la parte superior de JDBC, es muy fácil asignar objetos a tablas y aún usar SQL simple, todo está bajo su control.

Eclipse Link , por muchas razones, pero notablemente siento que tiene menos hinchazón que otras soluciones principales (al menos menos hinchazón en la cara).

Oh y Eclipse Link ha sido elegido como la implementación de referencia para JPA 2.0

SimpleORM , porque es sencillo y no mágico. Define todas las estructuras de metadatos en código Java y es muy flexible.

SimpleORM proporciona una funcionalidad similar a Hibernate mediante la asignación de datos en una base de datos relacional a objetos Java en la memoria. Las consultas se pueden especificar en términos de objetos Java, la identidad del objeto se alinea con las claves de la base de datos, las relaciones entre los objetos se mantienen y los objetos modificados se vacían automáticamente en la base de datos con bloqueos optimistas.
Pero, a diferencia de Hibernate, SimpleORM utiliza una estructura y arquitectura de objetos muy simple que evita la necesidad de análisis complejos, procesamiento de códigos de bytes, etc. SimpleORM es pequeño y transparente, se presenta en dos tarros de solo 79K y 52K, con solo un pequeño y opcional dependencia (slf4j). (Hibernate es más de 2400K más unos 2000K de tarros dependientes). Esto hace que SimpleORM sea fácil de entender y por lo tanto reduce el riesgo técnico.