Java - jdbc

Hola!!
Queria saber que solucion es mejor para tratar con base de datos en java. Si utilizar procedimientos almacenados o en cambio realizar las consultas sql directamente en codigo. ¿Cual de ellos es una solucion mejor? gracias

Lo normal es crear una buena estructura para el proyecto según tus necesidades.
Yo como mínimo suelo usar 3 capas para cualquier aplicación sencilla.
Una capa de interacción con el usuario, que digamos que incluye las pantallas y los componentes gráficos que el propio usuario va a ver y manejar. En esta capa no se desarrollan métodos de lógica, solamente se recogen los datos o las acciones generadas por el usuario al interaccionar con la pantalla.
Por otro lado, la capa de negocio o de lógica, que es la que "opera" con los datos o acciones intruducidas por el usuario. Es decir... si estás haciendo una calculadora, en la pantalla abrías recogido los números escritos por el usuario y el tipo de operacion que quiere hacer, sin embargo, la propia operación matemática la haría una clase albergada en esta capa.
Por otro lado, se crea la capa de acceso a datos. Es la única capa que accede a la base de datos, donde puedes crear sentencias SQL dinámicamente según tus necesidades. Es decir... si tras haber hecho una operación con la calculadora quieres almacenar el tipo de operación realizada y el resultado, tus clases de la capa de negocio deben llamar a alguna clase de acceso a datos que tenga un método al que le pases el tipo de operación y el resultado, y el mismo cree la SQL y la ejecute para almacenar los datos.
Los procedimientos almacenados son útiles para tareas repetitivas y automatizadas, como por ejemplo... usar un trigger para insertar logs en una tabla y cosas así. Pero para la gestión de SQL y demás... te recomiendo eso, una capa de acceso a datos donde tu mismo te creas los métodos para consultar, guardar, actualizar, etc.
Perdon x el tocho :P

Hola Mario!

Muchas gracias por contestar, ahora queria hacerte una pregunta. Tu en el acceso a base de datos que utilizas? statement o PrepareStatement? Yo he hecho lo que tu me has dicho me he creado una clase base de datos y he puesto los metodos correspondientes de consulta y actualizacion. Lo he hecho con PrepareStatement porque he leido que las instrucciones sql estan precompiladas y los select suelen ser mas rapidos (no se si eso sera cierto o no). Te pongo el codigo para que le heches un vistazo:

public class BD {
private Connection conexion;
private PreparedStatement pt;

public BD(String sql) throws ClassNotFoundException, SQLException {
Class.forName("com.mysql.jdbc.Driver");
conexion= DriverManager.getConnection("jdbc:mysql://localhost/hotel","root","loly");
pt= conexion.prepareStatement(sql);
}

// Metodo para actualizar datos: insertar, modificar y borrar
public void actualizar() throws SQLException{
pt.executeUpdate();
}

//Metodos para consultas: Devuelve un Resulset de la consulta
public ResultSet consulta() throws SQLException{
ResultSet s= pt.executeQuery();
return s;
}

public Connection getConexion() {
return conexion;
}

public Statement getPt() {
return pt;
}

public void cerrar() throws SQLException{
conexion.close();
pt.close();
}

Un saludo

Si te soy sincero, no tengo muy claras las diferencias, pero creo que una de las fundamentales es que a un PreparedStatement le puedes meter parámetros y a un Statement no. Por ejemplo así...

String sql_busca = "SELECT * FROM Clientes where nombre= ?";

PreparedStatement statement = conn.prepareStatement(sql_busca);
statement.setString(1,"Paco");

Así le señalas que en el lugar de la primera interrogación (en este caso la única) meta el nombre "Paco". Digamos que así es más facil realizar una sentencia que luego modificas mediante parámetros.

Yo la verdad es que uso la clase Statement porque a su vez me creé una clase a la que le paso ciertos parámetros y me pasa ya las sentencias como Strings. La desventaja que tendria Statement a priori es esa, que tendrías que preocuparte tú de "montar" el texto de la consulta en un String.

Por lo demás... creo que vas bien encaminada.

Si tienes alguna duda más o te puedo ayudar en lo que sea me lo dices ;·)

Hola mario!!
mira que he estao mirando y me salen todavia mas dudas. Mi pregunta es:
Cual es la forma correcta de utilizar las conexiones? es decir, supongamos que tengo un metodo que me valida si esta o no un cliente, debo abrir la conexion y cerrarla en este mismo metodo y cuando llame a otro abro una nueva conexion y la cierro o la dejo abierta siempre? Es que mi programa es un programa de gestion y continuamente estoy consultado y insertando datos... Tambien te queria hacer otra pregunta, puedo asociar varios statement a una misma conexion. Yo supongo que si no??
Espero haberme explicado bien. Un saludo

Hola mario!!
mira que he estao mirando y me salen todavia mas dudas. Mi pregunta es:
Cual es la forma correcta de utilizar las conexiones? es decir, supongamos que tengo un metodo que me valida si esta o no un cliente, debo abrir la conexion y cerrarla en este mismo metodo y cuando llame a otro abro una nueva conexion y la cierro o la dejo abierta siempre? Es que mi programa es un programa de gestion y continuamente estoy consultado y insertando datos... Tambien te queria hacer otra pregunta, puedo asociar varios statement a una misma conexion. Yo supongo que si no??
Espero haberme explicado bien. Un saludo

Lo de abrir y cerrar la conexión depende mucho del tipo de uso que hagas de la base de datos. Si es como tú dices y constantemente estás accediendo a datos, insertado, actualizando, borrando... entonces te conviene hacer una sola conexión y mantenerla abierta mientras la aplicación esté en funcionamiento.
Yo creo que respecto a crear varios statements, no tendrías problemas, supongo que cada objeto statement es totalmente independiente y se crea mediante el objeto connection simplemente porque necesita los datos de ese objeto para saber donde y cómo acceder a los datos.
Por otro lado, volviendo a lo de la conexión... yo por ejemplo, en una aplicación que tengo que usa un simple archivo de access como base de datos, tengo creada una clase llamada AccessConnection, que dentro tiene un campo estatico (private static Connection con). Después, para cada entidad (cada tabla) creo una clase de acceso a datos (por ejemplo ClientesDAO) la cual posee los métodos de acceso a datos propios para manejar dicho tipo de entidad (por ejemplo, guardarCliente, eliminarCliente, listarClientes... etc). Pues bien... cada clase DAO (Access Data Object) contiene un objeto de tipo AccessConnection, pero al tener declarado el objeto connection como estático, todos los objetos AccessConnection usan esa misma conexión, con lo cual se optimiza el acceso a los datos y no creas más conexiones de la cuenta (a menos que se haga por algún motivo específico, con una conexión a la base de datos tienes suficiente).
Si tienes mas dudas... ya sabes ;·)
Cuando llegue a casa si te interesa te puedo mandar algún fragmento de código de mis clases, que con ejemplos lo verás más claro.

Hola mario!!
Pues si puedes mandamelo, porque estoy echa un lio. Tambien te queria decir que las clases estas de acceso a base de datos serian las clases de la logica de negocio no?
me explico
Te voy a poner un ejemplo: Imagina un formulario de alta de cliente... Pues yo tendria mi clase que representa la interfaz grafica con todos los componentes definidos y despues tendria mi clase cliente que seria lo que tu dices la que accede a la base de datos.. Ten en cuenta que esta clase va a tener altas, bajas consultas... y demas entonces no veo logico que tengas que crear una clase cliente y otra clase cliente para acceder a la base de datos. Yo tendria una unica clase cliente que me instancia el objeto cliente pero ademas me guarda y consulta en la base de datos. No se si esto sera correcto pero yo lo veo asi. Bueno.. mandame como lo has echo tu ya le echo un vistazo y te digo vale?

Que nada chico, muxisimas gracias, mi aplicacion es para mi proyecto fin de carrera y la verdad que toy un poco verde en java. Un saludo.

Te agregué al msn, prometo que no es para intentar ligar contigo, solo para explicarte mejor las cosas x alli, jajaja.
A ver... como tú dices también estaría bien, sin hacer esa clase intermedia entre interfaz y acceso a datos, ya que tu aplicación parece sencilla y quizás no merezca la pena crear más clases que van a terminar siendo un poco redundantes.
De todas formas, te explico un poco el por qué de hacerlo tal y como yo te digo:
Una de las ventajas es que, en la clase intermedia (llamémosla Cliente) puedes tener un método que sea "loadCliente(id)" al que le pasas un identificador correspondiente con ese cliente. Dicho método, hace uso de su correspondiente clase de acceso a datos (ClienteDAO) la cual ejecuta la consulta correspondiente, y devuelve un objeto Cliente cargado al completo, con todos sus datos. Esto tiene como ventaja que ya tienes todos los datos de ese cliente en memoria, para usarlos cuando kieras. Si preguntas 3 veces el nombre del cliente, lo obtienes de la memoria, sin embargo, si lo hicieses mediante una consulta de la clase ClienteDAO, para cada vez que preguntas el nombre, haces una consulta a la base de datos. En este caso de ejemplo la consulta sería rápida, pero ponte en que fuesen consultas que tuviesen varios joins, etc. Sería una desventaje notable.
Por otro lado, tiene otra ventaja considerable y que es la mayor razón para hacer las cosas así. Y es que todas las bases de datos no se manejan igual, con lo cual, para una base de datos o para otra, los métodos de las clases DAO pueden ser distintos. Imagina que trabajas con hibernate... los métodos DAO no tendrán nada que ver con los que uses si accedes a una simple base de datos mediante ODBC, o si usas Oracle con JDBC.
¿A dónde nos lleva esto? A que tú, en tu clase Clientes, tendrias los métodos getEdad, getNombre, getDireccion... etc, que por ejemplo parten de un método llamado getCliente en la clase DAO. Al tener las clases separadas en distintas capas, si necesitas cambiar de base de datos, o de tecnología de persistencia de datos, solamente tienes que implementar tus métodos DAO, a tu método Clientes.getNombre(id) le dará igual que base de datos o qué tecnología uses, ya que el se limitará a llamar a un método ClientesDAO.getNombre(id), que será el que realmente tenga implementada la consulta, se encargue de crear la correspondiente conexión... etc.
Así, puedes crear distintas librerías y solamente cambiando la librería DAO, trabajar con una base de datos u otra, hibernate, hibatis... lo que necesites, implementando los métodos DAO correspondiente.
Hay multitud de matices que te convencerán más o menos, ya te contaré mas detalles si kieres en otro momento, pero por ahora ya te he dado bastante la tabarra :P
Por cierto... toda esta explicación no es para convencerte de que lo hagas así, sino para que sepas como se suelen plantear las cosas a la hora de crear una aplicación en el mundo profesional y sus razones. Por lo que tú me explicas... puede irte de lujo con el planteamiento que tu tienes ;·)