java - example - mybatis insert
Hibernate Vs iBATIS (6)
Cletus hizo un gran trabajo al resumir esta comparación. Hibernate funciona bien cuando controlas el modelo de datos y está más centrado en los objetos, mientras que iBATIS funciona bien cuando necesitas integrarte 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 más "magia" sucede con Hibernate. En otras palabras, los novatos pueden encontrar iBatis más fácil de usar y comprender.
Pero no estoy diciendo que prefiera iBatis, iBatis e Hibernate son simplemente diferentes como se dijo anteriormente.
Y, por cierto, si opta por Hibernate, tal vez considere utilizar anotaciones JPA y EJB 3.0 (JSR-220) estandarizadas de mapeo relacional / objeto provistas por Hibernate Annotations .
Para nuestra nueva reingeniería de productos, estamos en el proceso de seleccionar el mejor marco de Java. Como la consideración es ir por el enfoque agnóstico de la base de datos para el modelo, estamos trabajando en las opciones entre Struts + Spring con iBATIS o Hibernate. Por favor consejo cuál es el mejor ya que ambos ofrecen persistencia.
Considera lo que estás tratando de lograr. Por lo general, el modelo de segregación de respuesta de consulta de comandos funciona bien para dominios complejos.
La razón es que estás tratando de hacer una de estas dos cosas típicamente:
- Crear / actualizar / eliminar algunas entidades de dominio complejas
- Ejecute consultas analíticas de búsqueda (es decir, consultas de suma / agregación)
Hibernate funciona bien para el caso 1, lo que le permite hacer un POJO y persistir / actualizarlo. También lo hace rápidamente, a menos que tu dominio sea bastante grande.
myBatis es ideal para consultas de búsqueda (caso 2) donde solo desea una respuesta. Hibernate intentará cargar todo el gráfico de objetos y tendrá que comenzar a ajustar las consultas con trucos LazyLoading para mantenerlo funcionando en un dominio grande. Por el contrario, si solo quieres 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 de dominio y las Respuestas donde solo desea recuperar algunos datos.
Por lo tanto, considere estos dos casos y lo que hace su aplicación. Si tiene un dominio simple y solo obtiene información, use myBatis. Si tiene un dominio complejo y persisten entidades, use Hibernate. Si haces ambas cosas, considera un enfoque híbrido. Eso es lo que usamos en nuestro proyecto que tiene miles de entidades para mantenerlo bajo control. ;)
Hibernate es un ORM, lo que significa (en su nivel más básico) mapea instancias de objetos java en filas reales en una tabla de base de datos. En general, para pojo recuperado a través de Hibernate: cualquier manipulación y modificación a estos pojo aparecerá en la base de datos. Hibernate generará y ejecutará el SQL relevante en un 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 sentencias SQL y, por lo tanto, no es un ORM. También puede devolver pojo, por supuesto, pero no están vinculados a ningún tipo de contexto de persistencia.
Ambas herramientas hacen mucho más que lo descrito anteriormente, pero una es una ORM y la otra no.
El criterio para permitirle elegir cuál usar, creo, depende críticamente del modelo de base de datos con el que tiene que trabajar.
Por ejemplo, imagine un esquema extenso grande, que represente algún modelo de seguro. Se requiere que los desarrolladores recuperen datos e interactúen con ellos de forma tal que cumplan con el negocio en cuestión.
Los desarrolladores se van y nunca se espera que tengan los conocimientos comerciales necesarios para escribir todos los sql a mano (lo que Mybatis requeriría). Hibernate se adaptaría a un escenario así.
Los analistas comerciales definen el modelo de datos, las entidades, las relaciones y las interacciones, como es su experiencia. Los desarrolladores de Java luego usan Hibernate para "recorrer el modelo". Los desarrolladores de negocios pueden llegar a ser muy productivos rápidamente sin la necesidad de escribir SQL complicado propenso a errores para ejecutar en un esquema muy complicado.
En mi experiencia, tanto Hibernate como Mybatis se usan regularmente en el mismo proyecto.
Donde Hibernate se está utilizando para
- Funcionalidad CRUD general
- ''Caminando'' el modelo relacional ''objeto de dominio''
- Gestión de sesiones
y donde Mybatis se está utilizando para
- consultas ad hoc
- iniciar (e interactuar con) procedimientos almacenados
- admite consultas muy específicas o complejas
- admite consultas de búsqueda complicadas, donde los criterios de búsqueda son dinámicos y la búsqueda de resultados
Ibatis e Hibernate son bestias bastante diferentes.
La forma en que tiendo a verlo es esta: Hibernate funciona mejor si su vista está más centrada en el objeto . Sin embargo, si ves que está más centrado en la base de datos , Ibatis es una opción mucho más sólida.
Si tiene el control completo de su esquema y no tiene un requisito de rendimiento extremadamente alto, entonces Hibernate puede funcionar bastante bien. El modelo de objetos tiene un código bastante conveniente pero a un costo de complejidad enorme .
Si está tratando con 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 idioma que tendrá que aprender e incluso entonces probablemente encontrará casos en los que aún necesita escribir SQL. Lo que es más, es probable que en algún momento dedique medio día a encontrar la combinación correcta de XML, propiedades, anotaciones, etc. para que Hibernate genere una consulta SQL de rendimiento.
No hay una respuesta universal "A es mejor que B" para esta pregunta.
si ya está usando Spring, comenzaría con Spring JDBC en lugar de sumergirme 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 que haya adquirido Hibernate o iBatis.
No hay ninguna razón por la cual deba ser una decisión de "todo o nada". Usa lo mejor para tu situación.
ORM vs marco de persistencia
Hibernate es el marco de mapeo de relación de objeto (ORM) que mapea las clases de Java en las tablas de la base de datos. MyBatis es un marco de persistencia, no ORM. Mapea declaraciones SQL a métodos Java.
Esquema de la base de datos
Hibernate puede crear un esquema de base de datos de acuerdo con su modelo de Java, mientras que MyBatis no tiene dicha característica. Discusiones relacionadas:
Cache
Hibernate tiene un caché de primer nivel que es imposible de desactivar. Significa que si consulta un artículo a través de ORM y lo elimina directamente con SQL, permanece en el caché. Puede borrar explícitamente la memoria caché para obtener los resultados más actualizados de la base de datos. Discusiones relacionadas:
- ¿Los datos de carga de Jpa & Hibernate cambian de forma asíncrona en DB?
- ¿Qué son el almacenamiento en caché de primer y segundo nivel en Hibernate?
Optimista gestión de bloqueo
También existen diferencias para una gestión de bloqueo optimista:
MyBatis no admite el control de concurrencia optimista de forma nativa, a diferencia de las herramientas ORM como Hibernate / JPA con la anotación @Version.
Discusiones relacionadas:
- Control de concurrencia optimista
- Cómo evitar el problema de concurrencia en ACTUALIZAR a través de iBatis
Carga lenta
Hibernate intentará cargar todo el gráfico de objetos excepto los objetos que están marcados para la carga diferida. myBatis cargará los datos de acuerdo con una consulta SQL. La carga diferida puede mejorar el rendimiento, pero puede causar fugas de conexión si se usa con <property name="hibernate.enable_lazy_load_no_trans" value="true" /> . Discusiones relacionadas:
- org.hibernate.LazyInitializationException - no se pudo inicializar el proxy - sin sesión
- Resuelve el problema de Hibernate Lazy-Init con hibernate.enable_lazy_load_no_trans
Gestión de la sesión de Hibernate
Las operaciones de entidades como guardar, actualizar o eliminar se realizan a través de la Session Hibernate. Se requiere una buena comprensión de cómo implementar la estrategia de gestión de la sesión de Hibernate para evitar que la detached entity passed to persist y 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 sentencias de SQL en bruto para myBatis.
En cascada
Hibernate proporciona eliminación en cascada, eliminación de huérfanos y otras características para gráficos de objetos mientras que no están presentes en myBatis: para implementarlas, deberá escribir consultas SQL de forma explícita.
Consultas
En myBatis escribirás consultas SQL casi sin formato. Hibernate tiene múltiples opciones para formar consultas: SQL, HQL, Criteria API. A veces puede ser adecuado usar Criteria API cuando tiene muchos campos opcionales en los criterios. Proporcionaría un enfoque más estructurado para formular consultas y quizás evitar errores relacionados.