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.

7 comentarios :: Cuando usar / no usar Hibernate

  1. Estoy totalmente de acuerdo (incluyendo también el comentario en contra de los fanáticos, a pesar de que casi me considero uno =D). En la última aplicación en la que he trabajado he tenido que lidiar con los puntos negativos que destacas, lo cual ha resultado una seria molestia. Con esto me gustaría mostrar a quien lea el artículo que la lista de puntos negativos hay que ponerla en una balanza, ya que no son tan negativos como para descartar su uso (en mi opinión al menos).
    Para ponernos en antecedentes, es una aplicación de gestión, de "toma de decisiones" (no muchos usuarios concurrentes), que gestiona unos 10-12 elementos principales, que a su vez constan de otros tantos secundarios.
    -Modelo de datos existente:
    El modelo de datos de la aplicación es muy grande. A estas alturas la aplicación utiliza alrededor de 140 tablas, unas cuantas de ellas procedentes de esquemas existentes. Es cierto que usar tablas existentes me impidió generar el esquema directamente con Hibernate, teniendo que mapear "a mano", pero bueno. Aunque no se puede exprimir Hibernate al 100%, aún en este caso representa menos trabajo que escribir el SQL.
    -Claves primarias compuestas
    Cierto, un infierno. Otro equipo de desarrollo tenía un esquema en que casi todo eran claves compuestas. De verdad, nada como usar claves deferred (números incrementales, y punto).
    -Experiencia:
    Este ha sido el GRAN problema. Como comentas en una de mis entradas sobre una arquitectura con Hibernate, el factor humano es clave. Cuando lo vimos orientamos el proceso de contratación a experiencia en ello, pero es algo muy difícil de encontrar. Cuando entra alguien en el equipo sin experiencia en Hibernate, hay que dedicar tiempo de formación específica. Otras tecnologías se pueden abrir sobre la marcha, esta no. De hecho, en otro proyecto la formación inicial fue incluso menor, lo cual provocó un tiempo de arranque inadmisible, y además lo desarrollado, aunque funcionaba, no aprovechaba todo su potencial.

    En mi caso lo usamos porque el número de tablas ya existente no era grande, porque en nuestro esquema apenas habría claves compuestas, y porque aunque el equipo no tiene experiencia uno de los objetivos es que la consigan. Nuestro producto de desarrollo son principalmente aplicaciones para la intranet, e Hibernate es perfecto en estos casos.

    A las recomendaciones para usar Hibernate añadiría la siguiente:
    - Desarrollo de soluciones genéricas: hemos desarrollado "componentes verticales" (módulos que constan de modelos abstractos, DAOs, lógica de negocio, beans y componentes JSF) que nos permiten conseguir páginas CRUD "tipo" en escasos minutos. Por ejemplo, para las típicas situaciones de datos de tipo (código, nombre y descripción), en cinco minutos tenemos toda la pila funcionando.
    También para clases que se van a reutilizar en todo el sistema. Por ejemplo, tenemos un workflow que a las entidades que tienen un flujo asociado les almacena el historial de transiciones, estados, etc. Todo esto se puede gracias a la genericidad y reutilización.
    - Situaciones en las que el modelo de datos vaya a variar. Esto no es muy habitual, pero en metodologías ágiles, en las que se desarrolla sin haber cerrado los requisitos, es fundamental.
    - Uso de "todo el paquete": Hibernate Validator, Search, Shards (y Annotations). Los dos primeros proporcionan valor añadido. Me recuerda a lo que me ocurrió con Struts. El "núcleo" en sí mismo estaba bien, pero usar Struts Validator y Tiles destacaba todo su potencial. Con Hibernate, igual. El "núcleo" es muy interesante, pero definir las validaciones en el modelo, facilitar integrar la búsqueda, etc., son más puntos a favor.

  2. Hola Nacho. Es todo un placer tenerte por aquí. Muchas gracias por ampliar la lista positiva.

    Hibernate es una estupenda tecnología que merece la pena dedicarle tiempo y dominarla.
    De hecho es tan estupenda que una vez la aprendes es comprensible querer usarla en todos los proyectos, a veces a ciegas. La lista negativa tan sólo son una serie de puntos a tener en cuenta para situaciones donde merece la pena pensárse 2 veces si usar Hibernate.
    Y por supuesto es fruto de mi experiencia y de mi criterio personal.

    Es nuestro trabajo usar la balanza sabiamente.

  3. Julio,

    Estoy de acuerdo con el análisis que haces sobre Hibernate, yo lo uso hace bastante tiempo y le he dedicado varios posts, no me imagino volviendo a programar con JDBC los ABM. Además el Criteria API es la solución ideal para crear consultas dinámicas donde los filtros son opcionales.

    Saludos desde Uruguay,

    Federico

  4. Muy buena lista sobre razones para usar hibernate, en mi caso soy un novato de hibernate, hace apenas un mes que estoy en laburo nuevo y estoy aprendiendo hibernate a las piñas, menos mal tengo un compañero que se sienta a lado que sabe bastante y me saca de algunos kilombos
    y por ahora va bien........

  5. Hola, he seguido tus post sobre Web Services y googleando tambien me encontré con este sobre Hibernate ... de ambos temas me surgen las siguientes consultas: Para accesos a base de datos desde servicios web es recomendable usar hibernate? considerando que dicha base de datos es usado por varias aplicaciones que realizan gran cantidad de acceso y manipulacion de la data y los servicios poca en comparación a las aplicaciones ... que consideraciones hay que tener en cuenta para mantener la sincronización de la data tanto entre aplicaciones como los servicios?

  6. Hola Juan.

    La respuesta es depende :-) No hay una razón para no usar Hibernate en WS. Aunque si el WS sólo va a hacer lecturas, usar Hibernate (IMHO) tiene poco beneficio. Sobretodo si necesitas optimizar al máximo su rendimiento.

    Respecto a la integridad de datos, para eso están las transacciones.

  7. Que sucede si la aplicacion hace uso extensivo de procedimientos almacenados que sugieren usar?

Publicar un comentario