Capa de Persistencia: IBatis vs Hibernate

No es la primera vez ni la segunda que saco este tema, si buscáis en la Lista de correo seguro que encontráis alguno más J

El caso es que el otro día haciendo un par de entrevistas lo rememoré…

Cuando pregunté: “Y qué frameworks, herramientas y productos usarías en cada Capa”.

Los dos recomendaron JSF, Spring e Hibernate, uno de ellos con JPA y otro sin JPA. Qué típico!!!

…Dejaremos para otro post lo de JSF y Spring…

Cuándo les pregunté por qué usarían en la capa de persistencia si el cliente no les permitiese usar Hibernate (no sería el primer cliente verdad Melón J) ambos balbucearon, que si JDBC, Spring JDBC…

Recordáis esta tabla:

Otra opinión:

La mayor parte las diferencias entre Hibernate e iBATIS provienen del hecho de que el último basa su funcionamiento en el mapeo de sentencias SQL que se incluyen en ficheros XML. Eso significa que, al contrario que Hibernate, requiere conocimiento de SQL por parte del programador.

Por otra parte, permite la optimización de las consultas, ya sea con lenguaje estándar o con SQL propietario del motor de base de datos utilizado.

Con iBATIS, siempre se sabe lo que se está ejecutando en la base de datos, y tiene herramientas para evitar el problema de las “N + 1 consultas” y para generar consultas dinámicas muy potentes.

Cuando el modelo de datos es muy cambiante o es preexistente al desarrollo de la aplicación (y compartido con otras), iBATIS es un claro caso de uso.

También lo es cuando las relaciones entre las entidades del modelo son muy complicadas, porque con algo de trabajo se puede conseguir que el número de consultas que se pasan a la base de datos no sea excesivo, sobre todo en los listados descriptivos.

iBATIS ha ganado peso en la comunidad, hasta llegar a incorporarse al proyecto Apache, y su autor ha publicado un libro monográfico del producto en la serie “in action” de Manning.

Uno de los puntos fuertes de iBATIS es la estabilidad y la facilidad para encontrar dónde está el problema. Las transacciones y las cachés funcionan sin dar dolores de cabeza.

Respuestas

  1. […] IBatis es un motor de mapeo objeto-relacional del que hemos hablado ya en varios posts (comparándolo con Hibernate) […]

  2. bueno hace rato pregunte algo parecido a esto que bueno que este un poco mas extenso aqui, pero la verdad ¿JSF? la única vez que trabaje con jsf fue bastante molesto se necesita mucha maquina pa eso prefiero otra vaina

  3. una pregunta así como quien no debe (no encuentro un lugar de consulta) ¿java consume mas memoria que otros programas?

    1. No hay una respuesta sencilla…intentando ser genérico si que diría que Java consume más memoria que la mayoría de los lenguajes…

  4. lenguajes… no es programas es lenguajes

  5. Creo que el gran problema de Hibernate (Con JPA o sin él) es que requiere un periodo de aprendizaje mayor. Creo sin embargo que una vez que se domina, es mucho más potente que usar SQL o MyBatis. No estoy de acuerdo en que para un modelo cambiante sea mejor utilizar MyBatis. Es precisamente en esos casos cuando JPA o Hibernate son más útiles, ya que se pueden cambiar los modelos de datos sin demasiados problemas, especialmente si utilizas Criteria Querys o metamodelos.

    Si que veo muy útil a MyBatis como un sustituto del JDBC tradicional en aplicaciones en las que el rendimiento sea importante. Yo lo utilizo por ejemplo para hacer migraciones de datos, ya que tengo que hacer pocas manipulaciones con los objetos. Antes usaba Spring JDBC (Con algunos añadidos propios como placeholders con nombres), así que MyBatis es un buen sustituto.

    1. Suscribo al 100% lo que dices Rober2D2

Replica a Alfresco 3.4: Paso de Hibernate a IBatis « Java Mania Cancelar la respuesta