Para la reingeniería de nuestro nuevo producto, estamos en el proceso de seleccionar el mejor marco de Java. Como la consideración es optar por un enfoque independiente de la base de datos para el modelo, estamos trabajando en opciones entre Struts + Spring con iBATIS o Hibernate. Por favor, indique cuál es mejor, ya que ambos ofrecen perseverancia.
iBATIS e Hibernate son bestias bastante diferentes.
La forma en que tiendo a verlo es la siguiente: Hibernate funciona mejor si su vista está más centrada en los objetos . Sin embargo, si su vista está más centrada en la base de datos , iBATIS es una opción mucho más sólida.
Si tiene el control total de su esquema y no tiene un requisito de rendimiento extremadamente alto, Hibernate puede funcionar bastante bien. El modelo de objetos genera un código bastante conveniente pero con un costo de complejidad enorme .
Si se trata de un esquema de base de datos "heredado" en el que necesita escribir consultas SQL bastante complicadas, es probable que iBATIS funcione mejor.
HQL (Hibernate Query Language) es otro lenguaje que tendrás que aprender e incluso entonces probablemente encontrarás casos en los que todavía necesitas escribir SQL. Además, es probable que algunos dediquen medio día a averiguar la combinación correcta de XML, propiedades, anotaciones, etc. para que Hibernate genere una consulta SQL eficaz.
No existe una respuesta universal "A es mejor que B" para esta pregunta.
Considere lo que está tratando de lograr. Normalmente, el modelo de segregación de respuesta a consultas de comandos funciona bien para dominios complejos.
La razón es que, por lo general, intentas hacer una de dos cosas:
Hibernate funciona bien para el caso 1, lo que le permite crear un POJO y conservarlo / actualizarlo. También lo hace rápidamente, a menos que su dominio sea bastante grande.
myBatis es ideal para buscar consultas (caso 2) en las que solo desea una respuesta. Hibernate intentaría cargar todo el gráfico de objetos y necesitaría comenzar a ajustar las consultas con trucos de LazyLoading para mantenerlo funcionando en un dominio grande. Por el contrario, si solo desea una página POJO analítica, la implementación myBatis de la misma consulta sería trivial.
Debido a esto, myBatis es más rápido que Hibernate en SELECTS.
Estos dos casos son la diferencia entre los comandos en los que desea cambiar los datos del dominio y las respuestas en las que solo desea obtener algunos datos.
Entonces, considere estos dos casos y lo que hace su aplicación. Si tiene un dominio simple y solo busca información, use myBatis. Si tiene un dominio complejo y persiste entidades, use Hibernate. Si hace ambas cosas, considere un enfoque híbrido. Eso es lo que usamos en nuestro proyecto que tiene miles de entidades para mantenerlo bajo control. ;)
fuente
ORM vs marco de persistencia
Hibernate es un marco de mapeo de relaciones de objetos (ORM) que mapea clases de Java a tablas de bases de datos. MyBatis es un marco de persistencia, no ORM. Asigna declaraciones SQL a métodos Java.
Esquema de base de datos
Hibernate puede crear o validar el esquema de la base de datos de acuerdo con su modelo de Java, mientras que MyBatis no tiene dicha característica. También es conveniente para el entorno de prueba cuando está utilizando una base de datos en memoria. Discusiones relacionadas:
Cache
Hibernate tiene caché de primer nivel que es imposible de deshabilitar. Significa que si consulta el elemento a través de ORM y luego lo elimina directamente con SQL, permanece en la caché. Puede borrar explícitamente el caché para obtener los resultados más actualizados de la base de datos. Discusiones relacionadas:
Gestión optimista de cerraduras
También hay diferencias para la gestión optimista de bloqueos:
Discusiones relacionadas:
Carga lenta
Hibernate intentará cargar el gráfico de objetos completo excepto los objetos que están marcados para carga diferida. myBatis cargará los datos según una consulta SQL. La carga diferida puede mejorar el rendimiento, pero puede provocar pérdidas de conexión si se usa con
<property name="hibernate.enable_lazy_load_no_trans" value="true" />propiedades. Discusiones relacionadas:Gestión de sesiones de hibernación
Las operaciones de entidades como guardar, actualizar o eliminar se realizan a través de Hibernate Session . Requiere una buena comprensión de cómo implementar una estrategia adecuada de administración de sesiones de Hibernate para evitar
detached entity passed to persisty otros fenómenos relacionados con Hibernate.A veces puede tomar más tiempo tratar de comprender el comportamiento subyacente de Hibernate que agregar un poco más de trabajo y escribir declaraciones SQL sin procesar para myBatis.
En cascada
Hibernate proporciona funciones en cascada, eliminación de huérfanos y otras funciones para gráficos de objetos mientras no estén presentes en myBatis; para implementarlos, deberá escribir consultas SQL explícitamente.
Consultas
En myBatis escribirás consultas SQL casi sencillas. Hibernate tiene múltiples opciones para realizar consultas: SQL, HQL, Criteria API. A veces, puede ser adecuado utilizar la API de criterios cuando tiene muchos campos opcionales en los criterios. Proporcionaría un enfoque más estructurado para formular consultas y tal vez evitaría errores relacionados.
fuente
Cletus hizo un gran trabajo al resumir esta comparación. Hibernate funciona bien cuando usted controla el modelo de datos y está más centrado en los objetos, mientras que iBATIS funciona bien cuando necesita integrarse con una base de datos existente y está más centrado en los datos.
También creo que Hibernate tiene un poco más de curva de aprendizaje. Con iBATIS, es bastante fácil saber qué está pasando mientras que ocurre más "magia" con Hibernate. En otras palabras, los novatos pueden encontrar iBatis más fácil de usar y comprender.
Pero no estoy diciendo que debas preferir iBatis, iBatis e Hibernate son simplemente diferentes como se dijo anteriormente.
Y, por cierto, si opta por Hibernate, tal vez considere usar JPA estandarizado y anotaciones de mapeo relacional / objeto JPA y EJB 3.0 (JSR-220) proporcionadas por Hibernate Annotations .
fuente
Hibernate es un ORM, lo que significa (en su nivel más básico) que asigna instancias de objetos java a filas reales en una tabla de base de datos. Generalmente, para pojo's recuperados a través de Hibernate: cualquier manipulación y modificación de estos pojo's aparecerá en la base de datos. Hibernate generará y ejecutará el SQL relevante en el momento apropiado.
Mybatis (en su nivel más básico) es simplemente una herramienta para unir y ejecutar SQL que se almacena en archivos xml. No asigna instancias de objetos Java a filas en una tabla de base de datos, sino que asigna métodos Java a declaraciones SQL y, por lo tanto, no es un ORM. También puede devolver pojo's, por supuesto, pero no están vinculados a ningún tipo de contexto de persistencia.
Ambas herramientas hacen mucho más de lo descrito anteriormente, pero una es un ORM y la otra no.
Creo que los criterios que le permiten elegir cuál usar dependen fundamentalmente del modelo de base de datos con el que debe trabajar.
Por ejemplo, imagine un esquema extenso grande, que representa algún modelo de seguro. Los desarrolladores deben recuperar datos e interactuar con esos datos de una manera que se adapte al negocio en cuestión.
Los desarrolladores van y vienen, y nunca se esperaría que tuvieran los conocimientos comerciales necesarios para escribir todo el sql a mano (que Mybatis requeriría). Hibernate se adaptaría a un escenario como ese.
Los analistas de negocios definen el modelo de datos, las entidades, las relaciones y las interacciones, al igual que su experiencia. Luego, los desarrolladores de Java usan Hibernate para "recorrer el modelo". Los desarrolladores de negocios pueden volverse muy productivos rápidamente sin la necesidad de escribir un SQL complicado propenso a errores para que se ejecute en un esquema muy complicado.
En mi experiencia, tanto Hibernate como Mybatis se usan regularmente en el mismo proyecto.
Dónde se utiliza Hibernate
y dónde se utiliza Mybatis para
fuente
si ya está usando Spring, comenzaría con Spring JDBC en lugar de sumergirme directamente en Hibernate o iBatis. Si escribe su nivel de persistencia en términos de interfaces, no debería tener problemas para cambiar las implementaciones después de tener Hibernate o iBatis en su haber.
No hay ninguna razón por la que tenga que ser una decisión de "todo o nada". Utilice lo que sea mejor para su situación.
fuente