Cuando usar / no usar Hibernate

No me gustan los fanáticos. Y menos aún en nuestro mundo del desarrollo de software. Que si Linux o Windows. Que si Java es lento. Que si los EJBs son un infierno. Que si servicios web o REST. Que si Java se muere. Que si PHP, Ruby, .Net, etc... Son debates que he leido muchas veces y parecen más una discusión política o religiosa que un debate técnico. Y uno de estos debates eternos es el de si usar Hibernate o JDBC a pelo. Tomando a Hibernate como la estrella de los mapeadores objeto-relacional (ORM).

Si hay algo cierto en nuestro mundillo es que pocas son las preguntas que pueden responderse con sí o no. No hay que ser tan soberbio para pensar que cómo uno hace las cosas es la mejor manera posible para todos los casos existentes. Es responsabilidad de un buen ingeniero software analizar objetivamente la conveniencia de usar una tecnología o no.

Analicemos la conveniencia de usar Hibernate. Vaya por adelantado que he usado y uso Hibernate con excelentes resultados para muchos, que no todos, de mis proyectos. Por eso empezaré por las razones a tener en cuenta para no usar Hibernate:

• El modelo de datos ya existe, no se puede modificar y es complejo. Mapear el modelo de datos OO que has diseñado con un modelo de datos relacional existente no es sencillo. Mucho cuidado con los delete y con los triggers.
  


• Una buena parte de las claves primarias del modelo de datos son compuestas. Las claves compuestas en Hibernate son un coñazo, hasta el típico Provincia-Municipio te puede complicar la vida unas horas.


• Las operaciones de acceso a datos a realizar son en su mayoría de lectura. Vale, no tienes que escribir SQL, pero tienes que escribir HQL y no hay tanta diferencia.


• El equipo no tiene experiencia en Hibernate ni tiempo para formarse. Aunque en los tutoriales parezca una tecnología mágica y sencilla, dominarla precisa de tiempo y esfuerzo. Muchas de las críticas vertidas sobre Hibernate, en especial en temas de rendimiento, vienen de personas que no le han dedicado el esfuerzo que precisa.


• Es crítico optimizar las consultas realizadas sobre la base de datos. Por crítico me refiero a aplicaciones públicas de Internet con al menos cientos de usuarios concurrentes, donde los milisegundos y la latencia cuentan, nunca a comunes aplicaciones de gestión dentro de una intranet, donde se prefiere ahorrar en días o semanas de desarrollo antes que en unos milisegundos imperceptibles en ejecución.
  

En realidad el objetivo principal para usar Hibernate es recortar tiempo de desarrollo. Si todo o casi todo lo anterior no se da, será fácil cumplirlo. Pero además existen otros casos donde usar Hibernate es recomendable:

• Todos (o casi todos) los dao deben implementar las operaciones CRUD (Create, Read, Update y Delete). En este caso sí que te puedes ahorrar mucho tiempo y mucho SQL.


• La aplicación tiene formularios de búsqueda complejos. Reconozco que el api Criteria de Hibernate es una de mis debilidades.


• La aplicación debe funcionar sobre diferentes bases de datos. Ésta sí es una buena razón para querer abstrarse del SQL.


• Quieres tener la puerta abierta para usar caché sin complicarte. La integración de Hibernate con algunos sistemas de caché como EHCache es inmediata.