[JAVA] Acceso a Base de datos

NO, una vez que te conectaste ya está hecha la conexión, lo único que tenés que hacer es ejecutar diferentes querys, podés reutilizar el mismo objeto Statement o crear otro a partir de la conexión.

Suerte.

La idea es que tengas el objeto Connection como atributo de la clase que la crea. La conexion se crea una sola vez. Para que las demas clases puedan hacer consultas creas un metodo:
public Result ejecutar(String query) throws SQLException{
//aca armas el Statement o el PreparedStatement para consultar o insertar, o lo que quieras
Statement stmt = conn.createStatement();
Result r = stmt.executeQuery(query);
stmt.close();
return r;
}

para que las demas clases puedan hacer consultas y obtener los resultados

Ok ...lo voy a poner en practica ...Thanks

Mmmmm con respecto al tema diseño en mi caso particular no me gusta tener las queries y los statements asi como el codigo de conexión a la base de datos desparramado pro todo el codigo de mi aplicacion, y mucho menos dentro de formularios y codigos de la UI, porque al principio esta bueno, hay poco codigo pero al extender todo se vuelve inmanejable.

Yo usaria lo que se llama DataMapper o Data Access Object. En realidad es un objeto que encapsula todo el acceso a la base de datos para un cierto objeto determinado de mi negocio, supongamos que yo tengo un objeto Alumno definido asi:

Yo podria definir un DataMapper abstracto o DAO abstracto que tenga la funcionalidad comun a todos los DataMappers de mi aplicación, por ejemplo tener una referencia a la conexion a la DB, y codigo para instanciar una conexion y cerrar una conexion.

El codigo quedaría asi:
Y luego tendria diferentes DataMappers para cada objeto de mi negocio en este caso mi objeto Alumno, yo podria definir una clase AlumnoDataMapper que extienda de AbstractDataMapper y que tenga funcionalidad de insercion y acceso a base de datos

Fijate que con este approach, tenes en un unico lugar encapsulado todo el acceso a la base de datos, si alguna query cambia solo tenes que tocar un método de una sola clase y no x cantidad de queries distribuidas en x cantidad e formularios que usen esa query.

También tene en cuenta que si la estructura interna de tu objeto de negocio, en este caso Alumno cambia, solamente vas a tener que tocar en un único lugar como hacer la consulta a la base de datos para insertar o traer datos de la misma. El resto de la aplicacion solo se comunica con el DataMapper, le pasa objetos ya instanciados de tu clase de negocios y recibe objetos ya creados con datos traidos de la base de datos,.

Saludos
Pablo Martín Viva

Buenisimo Extraño Inocente....buena explicacion...ayer presente mi trabajo pero me dieron con un caño... querian que programe en 3 capas que al final no lo hize...porque nunca habia programado de esa forma....me dijeron que revea la forma de programar en 3 capas y lo que aportaste me va servir...Gracias

Ya que nunca hiciste este tipo de diseños te puedo dar algunos consejos mas para orientarte como sería. Generalmente hay dos tipos de modelos 3 capas. Está el clasico MVC (Model View Controller) que se usa en las aplicaciones Desktop y por otro lado esta el MVC Modelo 2 (Usado en apliacciones Web Java).

La idea es simple, tenes una capa de objetos representando la realidad que queres modelar, ahi codificas programaticamente todas las reglas del negocio o del "mundo" que queres modelizar. Por otro lado tenes una capa de presentacion que sabe como representar ese modelo programatico que creaste, y por ultimo hay una capa de control o interacion que conoce tanto al modelo como a la vista (El modelo es independiente de la vista y el controlador, esto lo hace reutilizable entre diferentes aplicaciones).

El usuario interactua con la vista y con el control, el usuario al ejecutar una accion con el aplicativo dispara una accion en el controlador que modifica el estado del modelo, y luego actualiza la vista o le indica que se actualize respecto al modelo.

Ahora esto se puede juntar en dos capas teniendo una capa de Vista - Controlador y otra de modelo, y además se le puede agregar una capa de persistencia (En este caso seria el acceso a la base de datos) pero acordate que se puede persistir a xml, a flat files serializar objetos guardarlos en bases de datos, etc.

Entonces es bueno a veces, encapsular todo el codigo de persistencia en una cierta capa y que las demas capas interactuen con ella, de esa forma si cambiamos la forma de persistir nuestros objetos lo hacemos solo ahi y no modificar cada capa que tenga que persistir objetos.

Otra ventaja de tener una capa de persistencia es la de abstraer a las otras capas de errores especificos de persistencia. Por ejemplo de la forma qu elo venias haciendo si lanzaba alguna excepcion de SQL el formulario tenia que saber que habia una excepcion de SQL que no deberia porque un formulario no debe saber que es SQL o que se está usando SQL. En cambio si tenemo suna capa de persistencia que internamente usa SQL, podemos atrapar ahi las excepciones propias de SQL y lanzar una excepcion a medida de nuestra aplicacion, de esa forma los clientes no están atados a manejar un tipo de excepcion especifico como la de SQL.

Cualquier cosa que necesites avisame que te doy una mano
Saludos
Pablo

Pablo sos un libro abierto explicando, realmente tenes mucha pasiencia. Si fuese moderador te premiaria... en fin,volviendo a lo nuestro yo me quedaria con un modelo centralizado. Es decir, una clase DBManager que mantenga una conexion o varias (pool de conexiones) y proveea el metodo que mencione arriba. De esta manera la conexion la administra solamente el DBManager y no se crea cada vez que construyo un objeto como el DataMapper. Igual esta buena la propuesta para tener en cuenta.
Suerte

En realidad me parece perfecta la idea Agustin, de tener la conexion abierta por todo el tiempo que necesites, pero considerá que los recursos del servidor son limitados y tienen un maximo permitido de conexiones y si accedemos simultaneamente dejando la conexion abierta por mucho tiempo podemos saturar los recursos del servidor.

Para eso recomendaría usar un pool de conexiones, básicamente lo que hace un pool de conexiones es lo siguiente: El pool tiene una maxima cantidad de objetos conexion a alocar, luego al iniciarse la aplicacion o el pool instancia las X cantidades de conexiones y las deja en espera para ser utilizadas.

Luego un cliente le pide al pool una conexion, el pool busca una de las que este libre y se la devuelve al cliente, el cliente la usa a conciencia y medida y luego la devuelve, y es el pool el que se encarga de limpiar la conexion y dejarla en un estado reutilizable. Con este approach se evita todo el costo de instanciacio de conexiones que en aplicaciones grandes puede ser muy costoso. Por otro lado no decae la performance en el servidor. Tambien esto permite que no se dejen conexiones abiertas, por cualquier lado, sino que es el mismo pool cuando se libera quien se encarga de liberar todas las conexiones.

Podemos usar el framework Apache - Jakarta Commons Pool para implementar pools de objetos genericos, y tambien en caso que deseemos usar pools de conexiones JDBC usar el framework Apache - Jakarta Commons DBCP (DataBase Connection Pool)

Tambien para hacer lo que vos comentas y mejorar la complejidad de manejar conexiones JDBC y excepciones vinculadas a JDBC, tenemos el framework Apache - Jakarta Commons DBUtils.

Acordemosnos que la forma en que vamos a obtener las conexiones JDBC tambien va a depender del tipo de aplicaicones que vayamos a desarrrollar, si usamos aplicaciones Desktop podemos crearlas manualmente o usar DBCP. Si usamos aplicaciones web, podemos pedirle al App Server que nos de un datasource para pedirle conexiones JDBC, o crearlas nosotros o usar DBCP o C3PO (Otro Pool de conexiones).

Saludos
Pablo

excelente, me viene bien los frameworks de apache... no estaba al tanto de eso :P