En este curso, te he contado cómo programar con JDBC moderno. Con él, tus proyectos y prácticas de escuela que necesiten usar JDBC estarán a la última usando todas las funciones que JDBC te ofrece desde hace ya bastante tiempo.
Sin embargo, pese a todo, hay una pregunta importante que hay que hacerse: ¿se sigue usando JDBC en primer lugar?
No quiero mentir.
JDBC ya no se usa tanto como antes.
Y es completamente normal.
A lo que aspiramos en nuestra vida cuando programamos es a crear abstracciones para que no tengamos que programar tanto, ni tan complicado, ni tan dificil de mantener.
Tal vez en los primeros días de la programación en Java sí que tendría sentido programar las sentencias SQL a mano, pero hoy en día lo normal cuando te enfrentes a un proyecto de programación en Java que requiera bases de datos, es que utilices alguna abstracción, como Hibernate, Panache, Spring JPA... en definitiva, un ORM o algo basado en JPA.
Para la mayoría de proyectos ya no es necesario simplemente escribir JDBC. Sin embargo, eso no quiere decir que JDBC esté obsoleto, ni de lejos. Esas tecnologías por debajo van a ser las que usen JDBC por nosotros. En otras palabras: tú no programas JDBC, porque alguien ya lo está haciendo por ti. Si no estuviese ahí JDBC, simplemente no podrías usar tu ORM ni tu conexión JPA.
En cualquier caso, esto no es malo. Irás más deprisa si simplemente usas esa abstracción para directamente trabajar con objetos, y dejar que un framework lo convierta a código SQL por ti.
De todos modos, seguirá siempre quedando gente que necesite usar JDBC para cosas puntuales. Estoy refiriéndome a queries super complejas de expresar con JPA, o con un lenguaje de consulta alternativo como HQL o Criteria. En algunas ocasiones, puede que una persona que tenga experiencia suficiente vea una query compleja con varios joins y decida que es más fácil tirar a mano una consulta SQL para hacer esa consulta concreta. Y en esas ocasiones, JDBC estará estupendo.
Consulta JDBC en una web de búsqueda de empleos como LinkedIn o InfoJobs y te encontrarás muchos empleos que requieren JDBC igualmente. Es verdad que no vamos a saber si realmente usan JDBC o no salvo que entremos en ese puesto, pero puede que verdaderamente los utilicen.
Hora de desvelar el truco de magia
Si alguna vez has utilizado Spring, y has utilizado Spring Data Source, te habrás dado cuenta que la ruta de conexión a la base de datos que especificas en el application.properties suele ser una URL de tipo JDBC, que empieza por jdbc, como por ejemplo jdbc:postgresql:// o jdbc:mysql://.
Esto no es casualidad.
Toma el código de un RestController como el siguiente:
@RestController
public class CitasController {
private CitasRepository repo;
public CitasController(CitasRepository repo) {
this.repo = repo;
}
}
Como probablemente sepas si has trabajado con Spring o con otros frameworks similares, aquí se suele usar mucho la inyección de dependencia para pasar clases colaboradoras. En el ejemplo que te acabo de dar, para usar el controlador CitasController, se necesita la colaboración de un objeto CitasRepository. Al usar un constructor que lo toma como parámetro, el contenedor IoC de Spring se ocupará de entregarnos ese dato al instanciar la clase.
Bueno, adivina lo que ocurre si agregas un parámetro al constructor de tipo DataSource y lo guardas en un campo:
@RestController
public class CitasController {
private CitasRepository repo;
private DataSource ds;
public CitasController(CitasRepository repo, DataSource ds) {
this.repo = repo;
this.ds = ds;
}
}
Este código funcionará e inyectará un DataSource. El DataSource que utiliza Spring concretamente. Prueba a ponerle un nuevo endpoint de pruebas que depure información del mismo y tal vez te lleves una sorpresa:
@GetMapping("/debug")
public String debugDataSource() {
try (Connection conn = this.ds.getConnection()) {
String driverName = conn.getMetaData().getDriverName();
String driverVersion = conn.getMetaData().getDriverVersion();
return driverName + " " + driverVersion;
} catch (SQLException e) {
return "Ha habido un error";
}
}
Cuando abras esto con tu navegador o con tu explorador de APIs preferido, tal vez te encuentres como respuesta algo como lo siguiente:
PostgreSQL JDBC Driver 42.7.3
De hecho, si cambias este código por lo siguiente:
@GetMapping("/debug")
public String debugDataSource() {
return ds.getClass().getCanonicalName();
}
Puede que descubras que Spring está usando un Hikari:
com.zaxxer.hikari.HikariDataSource
En definitiva, no es que JDBC ya no se use. Es simplemente que tú ya no tienes por qué usarlo para la mayoría de las cosas. Algo que está bien. JDBC es muy potente, pero también es innecesario y obliga a tirar mucho código que puede que no utilices. Sin embargo, está bien saber que si se te queda corto, vas a poder seguir usando JDBC para hacer cosas concretas.