64 votos

Hibernate, iBatis, Java EE o de otras Java herramienta ORM

Estamos en el proceso de planificación de una gran empresa de la aplicación. Nos estamos centrando nuestros esfuerzos en la evaluación de hibernación después de experimentar los dolores de J2EE.

Parece que la nueva API Java EE es más simple. También he leído algunas cosas buenas acerca de Hibernación y iBatis. Nuestro equipo tiene poca experiencia con cualquiera de los marcos.

Hay 5 principales comparisong puntos que me gustaría para determinar

  • La Curva de aprendizaje y la Facilidad de Uso
  • Productividad
  • Mantenimiento/Estabilidad
  • Rendimiento/Escalabilidad
  • La facilidad de Solución de problemas

Si se va a administrar a un equipo de ~6 a los desarrolladores J2EE experiencia que herramienta ORM usar y por qué?

109voto

cletus Puntos 276888

Permítanme tomar un crack en esto. Primero de todo, he escrito algunos sobre este tema en Usar un ORM o en formato SQL?. Específicamente a la dirección de sus puntos:

La Curva de aprendizaje y la Facilidad de Uso

Ibatis es acerca de SQL. Si usted sabe de SQL la curva de aprendizaje para ibatis es trivial. Ibatis hace algunas cosas en la parte superior de SQL, tales como:

  • grupo;
  • discrimina los tipos; y
  • SQL dinámico.

que tienes que aprender, pero el mayor obstáculo es SQL.

JPA (que incluye la Hibernación) en la otra mano intenta distanciarse de SQL y presentar cosas en un objeto en lugar de una manera relacional. Como Joel señala sin embargo, las abstracciones son goteras y JPA no es la excepción. Para hacer JPA usted todavía necesita saber acerca de los modelos relacionales, SQL, la optimización del rendimiento de las consultas y así sucesivamente.

Mientras que Ibatis simplemente tener que aplicar el SQL que saben o están aprendiendo, JPA se requieren para saber algo más: cómo configurar (XML o anotaciones). Con esto quiero decir que averiguar de que las relaciones de clave externa de una relación uno-a-uno, uno-a-muchos o muchos-a-muchos) de algún tipo, el tipo de asignación, etc.

Si usted sabe de SQL diría que el obstáculo para el aprendizaje de JPA es en realidad mayor. Si no, es más bien un resultado mixto con JPA permite efectivamente aplazar el aprendizaje de SQL por un tiempo (pero no de bajar de peso de forma indefinida).

Con JPA una vez que la instalación de las entidades y sus relaciones, a continuación, otros los desarrolladores pueden usar ellos y no necesita aprender todo acerca de la configuración de JPA. Esto puede ser una ventaja, pero un desarrollador todavía necesita saber acerca de los gestores de entidad, la gestión de transacciones, administrado vs los objetos administrados y así sucesivamente.

Vale la pena señalar que JPA también tiene su propio lenguaje de consulta (JPA-SQL), que tendrá que aprender si o no sabes SQL. Usted encontrará situaciones donde JPA-SQL no puede hacer las cosas que SQL puede.

Productividad

Este es uno para juzgar. Personalmente creo que soy más productivo en ibatis pero también estoy muy cómodo con SQL. Algunos argumentarán que son más productivo con la Hibernación, pero esto es debido posiblemente, al menos en parte, a la falta de familiaridad con SQL.

También la productividad con JPA es engañosa, porque en ocasiones se puede llegar a través de un problema con su modelo de datos o consultas que lleva una de medio día a un día para resolver como activar el registro y ver lo SQL tu JPA proveedor está produciendo y a continuación la combinación de ajustes y llamadas llegar a producir algo que es correcta y eficiente.

Usted simplemente no tiene este tipo de problema con Ibatis porque has escrito el SQL a ti mismo. Prueba ejecutando SQL dentro de PL/SQL Developer, SQL Server Management Studio, Navicat for MySQL o lo que sea. Después de la consulta es el derecho, todo lo que estamos haciendo es la asignación de entradas y salidas.

También me encontré con JPA-QL a ser más torpe que la pura SQL. Usted necesita herramientas distintas para un JPA-QL consulta para ver los resultados y es algo más que aprender. De hecho, encontré esta toda la parte de JPA más bien torpe y difícil de manejar, aunque a algunas personas les encanta.

Mantenimiento/Estabilidad

El peligro con Ibatis aquí es la proliferación en el sentido de su equipo de desarrollo sólo puede seguir añadiendo objetos de valor y las consultas que se necesitan, en lugar de buscar la reutilización mientras que JPA tiene una entitty por mesa y una vez que la entidad, que es todo. Consultas con nombre, tienden a ir en esa entidad, así que es difícil pasar por alto. Consultas Ad-hoc todavía puede ser repetido pero creo que es menos de un problema potencial.

Que viene en el costo de la rigidez sin embargo. A menudo en una aplicación que se necesitan y los pedazos de datos de diferentes tablas. Con SQL es fácil, porque se puede escribir una sola consulta (o de un pequeño número de consultas) para obtener todos los datos en un hit y ponerlo en una costumbre objeto de valor sólo para ese fin.

Con JPA se están moviendo hasta que la lógica en la capa de negocio. Las entidades son, básicamente, todo o nada. Ahora eso no es estrictamente cierto. Varios JPA los proveedores le permitirán parcialmente la carga de las entidades y así sucesivamente, pero aún no se está hablando de la misma discretos entitites. Si usted necesita datos de 4 tablas o hay 4 entidades o es necesario combinar los datos que desea en algún tipo de personalizado objeto de valor en el negocio o la capa de presentación.

Otra cosa que me gusta de ibatis es que todo el SQL es externo (en archivos XML). Algunos citan este es como una desventaja, pero no a mí. Usted puede encontrar los usos de una tabla y/o columna relativamente fácil mediante la búsqueda en los archivos XML. Con SQL embebido en el código (o donde no hay ningún SQL) puede ser mucho más difícil de encontrar. Usted también puede cortar y pegar SQL en una base de datos de la herramienta y ejecutar. No puedo dejar de recalcar lo suficiente en cómo muchas veces esto ha sido útil para mí a lo largo de los años.

Rendimiento/Escalabilidad

Aquí creo que ibatis gana las manos abajo. Es directamente a SQL y de bajo costo. Por su naturaleza, JPA, simplemente, no ser capaz de manejar el mismo nivel de latencia o de rendimiento. Ahora lo JPA tiene a su favor es que la latencia y el rendimiento sólo en raras ocasiones son problemas. Sistemas de alto rendimiento, sin embargo, existen y se tiende a la desaprobación de más peso pesado de soluciones como JPA.

Además, con ibatis puede escribir una consulta que devuelve exactamente los datos que quieres exactamente con las columnas que usted necesita. Fundamentalmente no hay manera de JPA puede vencer (o igualar) que al regresar entidades discretas.

La facilidad de Solución de problemas

Creo que este es un triunfo para Ibatis. Como he mencionado anteriormente, con JPA que a veces se pasan la mitad de un día llegar una consulta o entidad de producir el SQL que desea o el diagnóstico de un problema en una transacción falla, porque el gerente de la entidad trató de persistir un objeto no administrado (que podría ser parte de un trabajo por lotes donde se ha cometido un montón de trabajo por lo que podría ser trivial para encontrar).

Ambos se producirá un error si intenta utilizar una tabla o columna que no existe, que es bueno.

Otros criterios

Ahora usted no menciona la portabilidad como uno de sus requisitos (que significa movimiento entre vendedores de bases de datos). Vale la pena señalar que aquí JPA tiene la ventaja. Las anotaciones son menos portátil que, dicen, Hibernate XML (por ejemplo, el estándar JPA no tienen un equivalente para la Hibernación del "nativo" de tipo ID), pero ambos son más portátil que ibatis / SQL.

También he visto JPA / Hibernate utiliza como una forma de portátil DDL, lo que significa que ejecutar un pequeño programa en Java que crea el esquema de base de datos de configuración de JPA. Con ibatis usted necesitará una secuencia de comandos para cada base de datos.

La desventaja de la portabilidad es que JPA es, en algunos modos, un mínimo común denominador, es decir, la apoyó comportamiento es bastante común apoyado comportamiento a través de una amplia gama de proveedores de bases de datos. Si desea utilizar Analytics de Oracle en ibatis, no hay problema. En JPA? Bueno, eso es un problema.

10voto

StaxMan Puntos 34626

Una simple regla de pulgar entre iBatis y de Hibernación, es que si quieres más SQL/vista relacional del mundo, iBatis es mejor ajuste; y más complejas de la cadena de herencia, y menos a la vista directa a SQL, Hibernate. Ambos son ampliamente utilizados y sólida bueno marcos. Así que yo creo que ambos probablemente funcionaría bien. Tal vez leer un tutorial para tanto, a ver si suena mejor que la otra, y escoja una.

De las cosas de la lista, no creo que el rendimiento es muy distinto: el cuello de botella será casi siempre la base de datos, no marco. Para otras cosas, yo creo que los distintos desarrolladores prefieren uno u otro, es decir, no hay ninguna comúnmente aceptado prioridad (para iBatis vs Hibernación).

7voto

eqbridges Puntos 2143

La solución que ir con también depende de cómo cumple usted elija (o deben) estar con la especificación Java EE. JPA es "la norma" para el acceso a datos en Java EE sistemas, así que si estás en particular, acerca de la adhesión a que se debe utilizar (con algunas salvedades).

JPA es una estandarización de mapeo objeto-relacional de los sistemas. Como tal, no ofrece una aplicación, sino que simplemente define un enfoque estandarizado. Hibernate Gerente de la Entidad es una aplicación.

Desde JPA es un estándar a través de múltiples proveedores y puesto que todavía es bastante nuevo, carece de algunos de los más esotéricos de la funcionalidad que es valioso en algunos casos de uso (por ejemplo, una API de Criterios para la generación de SQL dinámico). Si vas con JPA plan en situaciones donde podrás nee para usar el modo de Hibernación directamente, o incluso JDBC directamente. Para situaciones como esta, un genérico DAO patrón es muy útil; puede modificar esta: Genéricas Objetos de Acceso a Datos para su uso en JPA Y JDBC con bastante facilidad.

JPA tiene algunas de las difíciles restricciones (especialmente si estás acostumbrado a Hibernate), e impone ciertos enfoques que son difíciles para los desarrolladores que son los más usados para escritura recta JDBC. Si usted está defendiendo a este como un enfoque, asegúrese de hacer su tarea sobre los pros vs contras de ORM vs. JDBC.

Si vas con JPA, una vez que has llegado a la curva de aprendizaje va a pagar en términos de desarrollo (particularmente si se aplica correctamente el mencionado patrón DAO), pero también en conseguir múltiples niveles de almacenamiento en caché de los resultados de la consulta. Si se hace correctamente (un gran "si", lo sé), yo he visto a este guapo beneficios.

Por último, si usted tiene un legado modelo de datos que tienen poca flexibilidad, Hibernate (JPA y) le dará más dolores de cabeza que tal vez vale la pena. Por ejemplo:

  • Si la base de datos no tiene candidato claves primarias (para la eficacia de hashCode y es igual a implementaciones), usted necesitará hacer análisis inicial en el que las columnas de definir una fila única, tal vez de simple, tal vez complejo dependiendo de la complejidad de su esquema;
  • Si usted no puede agregar la versión o columnas de marca de tiempo, se pierde de Hibernación de la capacidad de hacer el bloqueo optimista, y al final tienen que consulta antes de la actualización.

(Añadido en respuesta al primer comentario) Si tienes la suerte de re-diseño su base de datos, dos muy importantes consideraciones acerca de si va a ser usar un ORM:

  • Agregar un número de versión de columna para todas las tablas pertinentes para apoyar el bloqueo optimista.
  • Durante su análisis de los datos, decidir que no acepta valores null "clave alternativa" en la columna(s) que los desarrolladores deben utilizar para hashCode() & equals(). No utilice PK columnas en los métodos.

6voto

Rob Puntos 890

Añadir otra opción a la lista... echar un vistazo a:

Ebean ORM (www.avaje.org).

Su principal reclamo iba a ser más sencilla, más intuitiva modelo de programación de JPA o Hibernate. Específicamente, no tiene una Sesión de Hibernate o JPA EntityManager, no separado/objetos embargados (sin mezcla, de persistir, de color), la carga diferida simplemente funciona.

... aka mucho más sencillo de entender y de usar.

También puede utilizar su propio SQL con Ebean (para consultas, actualizaciones, procedimientos almacenados) y de la OMI coincide con Ibatis en la facilidad de uso wrt utilizando su propio SQL.

Si usted está buscando para usar el ORM en Java SE, entonces yo sugeriría que usted comprueba hacia fuera.

  • Licencia LGPL
  • El uso de JPA para la asignación (@Entity, @OneToMany etc)
  • De sesión menos API (sin mezcla, de persistir, al ras ... save() y delete() en su lugar)
  • "Objeto parcial" de apoyo
  • Consulta más grande de soporte (por objeto gráfico contexto de persistencia)
  • Consultas en segundo plano
  • Buen soporte para procesamiento por lotes
  • Automática de optimización de Consultas (a través de "Autofetch")

Saludos, Rob.

4voto

JavaGuy Puntos 228

Ser conscientes de que el uso de JPA/Hibernate (y probablemente la mayoría de las otras soluciones ORM) en no-trivial de aplicaciones multiproceso puede convertirse rápidamente en un verdadero PITA porque sesiones de base de datos tienen que ser confinado a un solo hilo (objetos de Sesión no son thread-safe). Agregar la carga diferida y el hecho de que la persistencia de las entidades pueden pertenecer a más de una sesión activa...y estás en un infierno de un paseo...

Puede que desee echar un vistazo a http://stackoverflow.com/questions/1664446/session-management-using-hibernate-in-a-multi-threaded-swing-application (o sólo la búsqueda de la 'hibernación multi-threaded').

Mi regla de oro (YMMV): Si la aplicación no se presta a algún tipo de petición/respuesta de ciclo (como un webservice por ejemplo) , quizás sea mejor usar algo más.

Por supuesto, otra solución sería el diseño de la aplicación en una forma que evita el mencionado marco de limitaciones. Cambiar de una aplicación de diseño de lo que puedo conseguir marco de XYZ a la obra deja un regusto desagradable, aunque.

De todos modos, sólo mis $0.02

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X