Los programadores de verdad no usan spring-jdbc?

Acabe de leer y me queda la duda.

¿El objetivo del post es comentar que documentacion de Tomcat recomienda usar JDBC en las aplicaciones que se desplieguen en ese contenedor para asegurar que las conexiones se cierren correctamente?
¿Que JDBC plano no es practico?
O hacer ver que los desarrolladores que no usan Spring-JDBC no son programadores de verdad?

¿?.

Creo que el título del artículo es una referencia a esos comentarios que siempre hay de que "los programadores de verdad usan X tecnología", que nació como burla de "los hombres de verdad hacen tal o cual cosa".
Es un comentario sarcástico: Los programadores de verdad no usan Spring-JDBC porque facilita demasiado las cosas.

Ese código es la manera de hacer las cosas con JDBC puro, dentro y fuera de Tomcat. Tienes que manejar la SQLException que es declarada y tienes que asegurarte que se cierra el ResultSet, el Statement y la conexión misma. Es un poco engorroso incluso si usas el patrón DAO, porque quien haga el DAO tiene que hacer todo ese código engorroso y si se te olvida un detalle, puedes tener problemas más adelante.

Spring JDBC, concretamente las clases JdbcTemplate y SimpleJdbcTemplate, te simplifican mucho la vida porque ya traen todo ese código de manera interna. Les pasas un DataSource y se encargan de todo el rollo de manejar la excepción y además la convierten a una RuntimeException de manera que no tienes que cachar nada si no quieres o no te corresponde. Supongo que Frank no puso el código equivalente usando Spring JDBC porque es una sola línea. Suponiendo que quieres obtener el resultado de un SELECT, como una lista de mapas (cada registro del ResultSet sea un mapa) entonces:

Y eso es todo. Adicionalmente el SimpleJdbcTemplate tiene métodos para leer un solo registro, para leer incluso un solo dato (para queries donde sólo quieres obtener una columna de un registro), para actualizar con INSERT/UPDATE/DELETE, para leer con un mapeador a instancias de la clase que tú quieras, etc.

Una vez que usas el soporte de Spring para JDBC, ya puedes admitir en público algo que ya sabías desde antes pero no querías aceptar: JDBC puro no es nada sencillo de usar.

Excelente explicación Chochos, no hubiera podido explicarlo mejor.

La definición en Wikipedia... que incluye algunas ligas a otras referencias.

Pues entonces alguna ocasión reescribí un sistema "de mentiras" (que usaba Hibernate), con Spring JDBC. "Liberé" el poder de SQL mejorando con ello mucho el desempeño al dejar que la base de datos hiciera lo que sabe hacer muy bien.

Para mi JDBC es un API de muy bajo nivel igual que DOM/SAX o Servlet: complicadas (o al menos tediosas) de programar y propensas a errores. Para construir aplicaciones deberían utilizarse APIs o frameworks de más alto nivel.

Saludos

Javier
Edit: Agregué unos paréntesis para aclarar que el sistema original usaba Hibernate. En ese caso en particular, buena parte de la lógica tenía más sentido resolverla con SQL que con Java.

Javier... no entiendo el sentido de tu comentario, pero te aclaro que Spring JDBC e Hibernate son dos cosas separadas (uno no usa Hibernate con Spring-JDBC, uno usa Hibernate con Spring-ORM, o Hibernate y Spring-JDBC, juntos, pero no revueltos)

Perdón. En esa ocasión reemplacé Hibernate con Spring JDBC. Y no extrañé ni tantititito a Hibernate.

Saludos

Javier Castañón

No no... los programadores de verdad ni siquiera usan Java :)

En realidad, yo creo que la utilización de una u otra tecnología se basa en los gustos de una persona. Es verdad que jdbc puro es mas tedioso de utilizar, al principio, por que como toda tecnologia que comienzas a usar tienes que aprender sus trucos, sin embargo despues de la primera aplicación usando jdbc la siguiente es más fácil, por que tal vez ya creaste clases que te ayuden en el manejo de errores o en la consulta o en lo que sea, yo por ejemplo una vez hize un un querier generico, algo muy básico a lo que es el criteria api de hibernate.

Ahora si hay quienes nuevos en la forma de consultar una base de datos prefieren no complicarse y usar spring-jdbc, que como dijo ezamudio es mas fácil y rapido, pues adelante, hibernate es igual de fácil de usar y hasta mejor me atrevo a decir por que te crea las tablas o las actualiza, sin embargo es un poco mas dificil de configurar.

Saludos

Usar Spring JDBC o JDBC puro (o Hibernate, que no sé por qué y cómo se volvió parte de la discusión) depende del gusto de la persona? ... y yo todos estos años haciendo evaluaciones técnicas para decidir qué cosa es mejor usar en un proyecto, según los requerimientos del mismo... que si el performance es un factor, o la memoria disponible, manejo de transacciones, mantenibilidad, licencias, curva de aprendizaje...

Originalmente estábamos comparando solamente JDBC puro contra Spring-JDBC. Es cierto que muchas veces tuvimos que usar JDBC solito y a veces terminamos haciendo nuestra mini-librería de código para simplificar las cosas y se parece un poco a lo de Spring JDBC. Pero las ventajas de usar Spring JDBC en vez de hacer nuestra propia librería son:

• Spring-JDBC se ha vuelto un estandar de facto por lo que otros programadores en el presente o en el futuro podran entender mejor mi codigo, en vez de tener que analizar la libreria que yo hice.
• El codigo de Spring JDBC ha sido revisado por un equipo de gente y por otras personas ajenas al equipo, probado por muchisima gente, y ha sido depurado mucho mejor de lo que mi minilibreria o miniclase podria ser porque solamente la usamos yo y dos compadres mios en el proyecto.
• Si hago una libreria, es codigo del cliente o de la empresa donde trabajo, a menos que desde antes de la primera linea de codigo haya un acuerdo en que la libreria sera de mi propiedad. Pero normalmente todo es trabajo por encargo de modo que si me cambio de empresa pierdo acceso a dicha libreria. Pero si uso Spring JDBC puedo usarlo en otros trabajos despues.
• Si llego a encontrar defectos en Spring JDBC, puedo corregirlos porque tengo acceso al codigo fuente, y avisar a los autores y lo podran corregir para la siguiente version; esas correcciones y otras las voy a tener en la siguiente version, independientemente del proyecto o empresa en que me encuentre trabajando.

No conozco a nadie que se pueda dar el lujo de simplemente usar un framework u otro simplemente porque le gusta mas. Hasta los independientes deben de justificar el uso de un framework sobre otros por razones tecnicas con los clientes que asi lo piden. Y si trabajas en una empresa y tienes la oportunidad de decidir que herramientas usar, hay que presentar una justificacion de la decision.

En cuanto a Hibernate, estamos comparando un poquito peras con manzanas, porque la discusion era de JDBC solito o Spring JDBC, dos maneras de usar la misma tecnologia; Hibernate es un ORM y ya cambia mucho el enfoque de la herramienta. Pero aun asi podria justificarse el uso de JDBC sobre Hibernate en algun proyecto (por ejemplo, cuando la aplicacion corre en un equipo con recursos muy limitados o por compatibilidad con alguna otra cosa que no permite el uso de Hibernate).

Hola, estoy totalmente de acuerdo contigo ezamudio, pero si hicieras un sondeo te darás cuenta que la mayoría se "casa" con un framework por x o y razón (principalmente por cuestiones de "autoridad", seguir al lider, etc.) y lo usa para todos sus proyectos aunque no amerite, su justificación se basa en las bondades del framerwork por si mismo y no en si es adecuado para al proyecto, por lo que te das cuenta que mucho tiene de preferencia personal. Por ello a mí no me sorpendió el comentario de "En gustos..." aunque tampoco esté de acuerdo con el mismo.

Saludos.

Estoy de acuerdo en que uno debe hacer una seleccion de tecnologias dependiendo de la necesidad del proyecto, pero aca entre nos, nunca haz hecho una tabla que te lanze una accion al doble clic de una fila o que te genere un popup al clic secundario mostrandote una lista de acciones que te le pasaste previamente, y que este codigo lo uses en varios proyectos? o siempre reescribes todo?
Decir que uno prefiere usar spring-jdbc a jdbc puro es meramente el gusto de una persona, por que el gusto interviene mucho en la forma de pensar, o dime entonces por que algunos usan netbeans en lugar de jcreator? Tu prefieres programar en jEdit o en eclipse? si somos objetivos eclipse es mejor, por el refactoring, precompilado, manejo de proyectos, decidir que jvm usar y muchas otras opciones que jedit no tiene, que aunque existen plugins, no funcionan al 100% todas, pero por que muchos continuan usando jEdit? por que inclusive algunas personas dicen que los programadores de verdad no usan spring-jdbc?

El tema se centra en dos tecnologias, que a final de cuentas una depende de la otra, pero la realidad el tema va mas alla de una simple reflexion objetiva, similar la hecho de que existen como 100 distribuciones de linux quien sabe por que.

Saludos

Yo creo que sí hay algo aquí de peras y manzanas. Como dice ezamudio, se supone que se debiera utilizar la herramienta más adecuada para cada proyecto de acuerdo a los requerimientos. También están los estándares, que pueden imponer el uso de determinada tecnología. Entonces debería quedar en un tercer lugar utilizar tecnologías por cuestiones subjetivas: "por gusto", "por costumbre", "porque así lo hago siempre", "porque me da flojera hacerlo de otra manera", "porque no creo que haya una manera mejor", "me cae mejor" etc.

Nótese que no niego que el gusto personal juega un papel importante, y más en una profesión que se asemeja más a la artesanía que a la ingeniería (IMHO), pero quienes lo aplican preponderantemente me parece que utilizan un argumento técnicamente pobre.

Ahora bien, creo que es perfectamente posible racionalizar de una manera objetiva la razón para utilizar como servidor una distribución CentOS o RHEL, y cuando hay empate dejar decidir al gusto personal, lo cual me parece muy válido.

Sin embargo, al igual que una distro Linux de escritorio, un editor o IDE no es algo que se vaya a quedar en tiempo de producción ejecutando en un servidor. Si usaste vi o Eclipse en tu máquina quizás no es algo que me preocupe mucho, pero las librerías que hayas empleado en una aplicación que pertenece a una organización, probablemente sí sea algo en donde quisiera ponerle límites a los gustos personales, al menos de quienes yo considerara que no debiesen tener ese poder de decisión.

Saludos

Javier Castañón

por que inclusive algunas personas dicen que los programadores de verdad no usan spring-jdbc?

Ya quedó aclarado en varios comentarios previos que esto fue sarcasmo, una referencia a la frase de "real programmers don't use $SOME_TECH".

Usar Spring-JDBC sobre JDBC no depende meramente del gusto de una persona. Si no te dejan usar Spring en el proyecto no tienes la opción de usarlo. Si en cambio se está usando Spring en el proyecto, debes dar una MUY buena razón por la cual prefieras usar JDBC solito en alguna parte en vez de Spring-JDBC (todo esto asumiento que estás trabajando en un proyecto dentro de un equipo organizado y con un líder técnico, etc).

Como dice Javier, si quiero usar Eclipse, jEdit, NetBeans, emacs, vi, etc es muy mi problema, siempre y cuando no afecte a los demás miembros del equipo; ahí sí es cuestión de gustos, tanto como la música que puedas escuchar mientras programas. Pero las librerías que utilizo en el proyecto afectan el producto final y eso sí es muy importante. Si el cliente resulta estar en contra del software libre y no quiere que haya nada de eso en su producto final, no puedo usar Spring-JDBC y tendré que replicar esa funcionalidad haciendo mis propias clases desde cero y fijarme que no parezca un plagio para no meter a nadie en problemas en el futuro.

Ahora bien, las razones técnicas a veces resultan en un empate entre dos o más tecnologías similares y entonces puede ser que entre el gusto personal, que prefieras usar uno u otro framework de ORM o web porque te gusta que usa menos XML o que te permite un control más fino de lo que ocurre en la aplicación, etc. Pero a veces hasta esos gustos traen una razón técnica detrás...

En cuanto a las distros de Linux, no es ningún misterio por qué hay tantas. Cada una se enfoca en algo distinto. RedHat es para servidores empresariales; CentOS también pero CentOS toma lo que ya dejó RedHat atrás, pero igual te da soporte a largo plazo. Fedora usa las versiones más recientes del software que incluye, aunque no sean todavía lo más estable. Ubuntu se centra en facilidad de uso, para compus de escritorio, portátiles etc (va enfocado a usuario final), y tienen su versión para server por no quedarse atrás, enfocándose también en facilidad de uso. Finalmente Ubuntu es un derivado de Debian que tiene una filosofía detrás de la distribución y que es distinta de la de RedHat o Fedora. Gentoo es para los que quieren tener todo super optimizado para su hardware y por eso está hecho para que cuando instales cualquier paquete, baja los fuentes y se pone a compilar todo. Y así cada una tiene su filosofía, su historia, etc. No olvides que Linux a fin de cuentas es el puro kernel; todos los demás programas que van encima, desde los programas más simples de línea de comando hasta los manejadores de ventanas, ambientes gráficos, herramientas de desarrollo y todas las demás aplicaciones, son lo que componen la distribución y la manera en que se manejan las versiones, actualizaciones, etc es lo que va variando de una a otra. A fin de cuentas, choice is good y aunque solamente uses una distro, es bueno que haya otras 99 porque no a todos nos gusta lo mismo o no podemos usar lo mismo en los proyectos que tenemos.

Si el cliente resulta estar en contra del software libre y no quiere que haya nada de eso en su producto final, no puedo usar Spring-JDBC y tendré que replicar esa funcionalidad haciendo mis propias clases desde cero y fijarme que no parezca un plagio para no meter a nadie en problemas en el futuro
Aqui tocas algo muy importante, el cliente está diciendo de antemano que no quiere que uses spring-jdbc, por lo que tal vez e te va a proporcionar la lista de tecnologias a utilizar o quiere que tu las propongas y el decidirá, pero eso ya es aparte, si a ti te dicen: hazme un sistema que haga esto y aquello y me vale wilson que uses mientras funcione, entonces ¿que utilizas?

Y ps bien, ya entendi eso del sarcasmo, creo que me emocioné de mas cuando escuche: spring-jdbc vs jdbc directo, me pareció tonta el comentario como cuando dicen: CentOS es mejor que ubuntu o red hat o gentoo o debian, god si todos usan el kernel de linux, bueno pero esa es mi opinión y no entra en el tema.

sobres

De jdbc a distribuciones de Linux en un solo post... a eso le llamo versatilidad!!!
Solo quiero comentar que, si bien a veces te tienes que fregar a lo que te dice la empresa (yo por ejemplo, trabajo ahora en sistemas bancarios), a veces tienes oportunidad de proponer (en mi empleo anterior propuse una solucion a base de google web toolkit) entonces, creo que un factor importante es.... donde llegues a trabajar, en fin, este hilo se me hizo muy interesante, y con respecto al comentario de amnesiac ... no es mala onda, pero si no aportas algo util, no critiques....