Barrapunto

Casi totalmente de acuerdo contigo. La verdad es que estuve viendo un ORM para usar, más que nada porque estaban de moda y quería saber bien qué era eso. Al final me decidí por Hibernate, pero bueno, en esencia es lo mismo que iBatis.
Ahora te voy a poner algún ejemplo de lo que no estoy de acuerdo.
1) He visto gente por ahí que no tiene idea de lo que son las consultas SQL. Algunos directamente no saben hacer nada en SQL y otros van de listillos y he visto un inner join que igualaba una select "on fly" que tenía una subconsulta. Claro, tardaba un "pelín" en ejecutarse eso...Para este tipo de "programadores" que andan sueltos por ahí lo mejor es una librería que le impida hacer burradas. Por cierto, no estaba en mi mano echar al individuo de la consulta, sino...

2)Si el proyecto requiere que se pueda ejecutar en diversos motores de BD. La verdad es que es un requisito un tanto rebuscado, pero una vez CASI nos topamos con él. Un ORM te puede ahorra trabajo.

3)Sobre J2EE. Si vas a usar esto para hacer una WEB de propaganda... bueno es un problema. No está pensado para eso, sino para proyectos grandes, y cuando se refiere a transacciones distribuidas no se refiere a transacciones en un único motor de BD, sino en varias BD de motores distribuídos. Vamos, esto está pensado para bancos y empresas de la leche. Lo que pasa es que se usa como el "trasero" esto de J2EE, y supongo que porque es "guay". La aplicación práctica de J2EE es muy limitada, me refiero ¿cuántos proyectos va a ser distribuidos de verdad con transacciones? Pocos, muy pocos, lo que pasa es que vende mucho decir que has hecho algo con J2EE+Spring3+Struts2+Hibernate+Tiles+JSF+Jquery+ZF +...+n bueno, para al final una porquería de tienda online.

Por cierto, después de usar Hibernate me he quedado con esas 3 conclusiones, y creo que lo más rápido si controlas SQL "de verdad" (cosa que no tiene tanto mérito ni es tan complejo) tirar tus mismas consultas es lo más para la mayoría de los proyectos de tipo medio y bajo tamaño. Al final me monto una pequeña librería propia y básica para ayudar con las consultas simples y que la puedes reutilizar siempre en todos los proyectos.

4)Y no viene al caso, pero ahora estoy ayudando en un proyecto que no he diseñado yo. El caso es que el que lo lleva tuvo la idea de meter toda la lógica en la BD, es decir, la capa de datos en BD mediante Vistas y procedimientos almacenados. Podría parecer buena idea... La idea era no tener que usar ningún join en código.... lo desaconsejo totalmente. Es un coñazo llevar las versiones de las tablas/vistas/procedimientos, como también el trabajo en grupo (coñazo con el control de código fuente). Los cambios son horribles porque si hay varias BD de pruebas, tienes que aplicar una simple columna a mayores en una vista, bd por bd ejecutando el cambio. El código SQL no es visible a simple vista, porque está en la BD y si quieres buscar por todo el código no aparece... horrible. Ya te digo que el que lleva el tema está desencantado con esta decisión, pero ahora está hecho...