Reflexiones Tecnológicas: Tecnolitis frente a KISS

Pasa el tiempo y con el tiempo mi tecnolitis también (así denominó un director hace un tiempo a la manía/obsesión del arquitecto por definir el megasistema/megaframework/megaaplicación, aunque este sólo tenga que mantener 4 tablas)…también podríamos decir “lujuria tecnológica” :)

Una de las Capas en la que más sobre-arquitecturamos es en la de Persistencia…tanto que últimamente hasta IBatis me parece sobredimensionado (bueno, aún no pero a todo se llega).

Bien es cierto que con Spring ROO a nivel de desarrollo el modelo JPA (ficheros de configuración, integración con Spring…) queda muy recubierto y sencillo pero aún quedaría el tema del rendimiento…cuantos os habéis acordado de JDBC cuando Hibernate lanza Query tras Query y tarda 3 veces más de lo esperado…

Así que llevo tiempo buscando “otras” soluciones más sencillas, en el fondo frameworks para trabajar con JDBC de forma más simple y rápida pero sin llegar a ser un motor de persistencia.

Creo que puedo decir que tengo bastante experiencia en este tema y he trabajado con Entity Beans (esto nadie que lo haya probado lo echará de menos seguro), Castor JDO (hace más de 7 años), TopLink (hará unos 5, no Dani? :)) pasando por varios proyectos con Hibernate y JPA y hasta uno con el malogrado estándar JDO (que no me extraña) con en lo que a motores de persistencia se refiere. También he usado IBatis y Spring JDBC en aproximaciones más ligeras…

…pues bien…

…busco algo aún más simple…

De estos el único que cubre mis expectativas es IBatis, pero echo en falta algunas características en cuanto a la forma de “mapear” clases a tablas que creo que se pueden aún simplificar.

Envuelto en esta tarea os iré contando mis experiencias…de momento he probado 2 que mooooooolan muchooooo…ya os contaré…

¿Se os ocurre alguno?

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 413 seguidores

%d personas les gusta esto: