0% encontró este documento útil (0 votos)
12 vistas8 páginas

Java-Repaso de JDBC

Conceptos básicos de API de Java para conectarse con las bases de datos

Cargado por

nicolas Sosa
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
12 vistas8 páginas

Java-Repaso de JDBC

Conceptos básicos de API de Java para conectarse con las bases de datos

Cargado por

nicolas Sosa
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 8

Contenido

1. Conexión a base de datos MySQL de forma estructurada..................................1

2. Conceptos............................................................................................................2

2.1 Clases de dominio o entidad............................................................................2

2.2 Data Access Object (DAO)...............................................................................2

2.3 Cohesión y acoplamiento.................................................................................2

2.4 Bajo acoplamiento............................................................................................2

2.5 Alta cohesión....................................................................................................3

2.6 Alta cohesión y bajo acoplamiento...................................................................3

3. Transacciones con JDBC.................................................................................... 3

4. Patrones de diseño y buenas practicas...............................................................5

4.1 Capa de datos con JDBC.................................................................................5

4.2 Patrones de diseño.......................................................................................... 6

5. Pool de conexiones..............................................................................................6

1
1. Conexión a base de datos MySQL de forma estructurada

2. Conceptos

2.1 Clases de dominio o entidad

2
Son aquellas clases que están representando una tabla proveniente de una base de
datos.

2.2 Data Access Object (DAO)


Es aquella clase que realiza las operaciones de CRUD sobre la base de datos

2.3 Cohesión y acoplamiento


 El objetivo del diseño es minimizar costos de desarrollo.
 La cohesión es la medida en la que un componente de software se dedica a
realizar solo la tarea para la que fue creada, delegando las tareas
complementarias a otros componentes
 El acoplamiento es la medida en la que los cambios de un componente
tienden a necesitar cambios de otro componentes. En otras palabras, el
acoplamiento mide el grado de dependencia entre dos o más elementos.
 El objetivo del diseño de software es tener una alta cohesión y bajo
acoplamiento entre sus componentes de software.

2.4 Bajo acoplamiento


El bajo acoplamiento se refiere a una relación en la cual un módulo interactúa con
otro vía una simple y estable interfaz y no necesita conocer la implementación
interna del otro módulo.

Esta práctica nos ayuda a separar en capas, las diferentes funcionalidades o clases
del programa, teniendo una relación mínima con cada una de ellas

2.5 Alta cohesión


Se conoce como alta cohesión cuando cada clase realiza únicamente su tarea.

En la programación orientada a objetos, si los métodos que sirven a una clase


tienden a ser similares en muchos aspectos, entonces se dice que la clase tiene una
alta cohesión. En un sistema altamente cohesivo, la legibilidad y reusabilidad del
código es mayor, mientras que la complejidad se mantiene manejable.

2.6 Alta cohesión y bajo acoplamiento


Es importante tener una alta cohesión y bajo acoplamiento, y no al revés, para
lograr un buen diseño de software.

3
3. Transacciones con JDBC
Una transacción es un conjunto de operaciones sobre una base de datos que se
deben ejecutar como una unidad.

Hay ocasiones en las que es necesario que varias operaciones sobre la base de
datos se realicen en bloque, es decir, que se ejecuten o todas o ninguna, pero no
que se realicen unas sí y otras no.

Si se ejecutan parcialmente hasta que una da error, el estado de la base de datos


puede quedar inconsistente. En este caso necesitaríamos un mecanismo para
devolverla a su estado anterior, pudiendo deshacer todas las operaciones
realizadas.

Como ejemplo, supongamos que vamos a reservar un vuelo desde Alicante hasta
Sydney. Para llegar a Sydney tenemos que realizar varias escalas. Tendremos que
reservar un vuelo de Alicante a Madrid, otro de Madrid a Dubai y otro desde Dubai a
Sydney. Si representamos cada reserva como un insert en la base de datos
tendremos las siguientes instrucciones:

4
Un objeto Connection por defecto realiza automáticamente cada operación sobre la
base de datos. Esto significa que cada vez que se ejecuta una instrucción, se refleja
en la base de datos y no puede ser deshecha. Por defecto está habilitado el modo
auto-commit en la conexión.

Los siguientes métodos en la interfaz Connection son utilizados para gestionar las
transacciones en la base de datos:

Para iniciar una transacción deshabilitamos el modo auto-commit mediante el


método setAutoCommit(false). Esto nos da el control sobre lo que se realiza y
cuándo se realiza.

Una llamada al método commit() realizará todas las instrucciones emitidas desde la
última vez que se invocó el método commit().

Una llamada a rollback() deshará todos los cambios realizados desde el último
commit(). Una vez se ha emitido una instrucción commit(), esas transacciones no
pueden deshacerse con rollback().

5
4. Patrones de diseño y buenas practicas

4.1 Capa de datos con JDBC

Nota: La programación en N-Capas o en capas no es un patrón de diseño, sino más


bien un tipo de arquitectura.

4.2 Patrones de diseño

6
5. Pool de conexiones
Un pool de conexiones es un conjunto limitado de conexiones a una base, que es
manejado por un servidor de aplicaciones de forma tal, que dichas conexiones
pueden ser reutilizadas por los diferentes usuarios. Este pool es administrado por un
servidor de aplicaciones que va asignando las conexiones a medida que los clientes
van solicitando consultas o actualizaciones de datos.

Tanto las aplicaciones web como las aplicaciones win 3 capas utilizan este pool de
conexiones, los que las hace arquitecturas ventajosas frente a una arquitectura
tradicional de cliente / servidor (2 capas).

El pool permite tener centralizado y controlado el manejo de las conexiones a la


base de datos, ya que el acceso a la misma no se hace desde el cliente, como en
una aplicación en 2 capas, sino que en este tipo de aplicación el acceso es
realizado por el servidor de aplicaciones. Para ello podemos utilizar un pool de
conexiones a la base de datos.

La cantidad de conexiones abiertas a una base de datos es limitada, dado que


consumen muchos recursos del servidor de base de datos, y se requiere memoria y
tiempo del procesador por cada nueva conexión. El manejo de un pool favorece la
escalabilidad y performance de una aplicación.

En las aplicaciones cliente/servidor tradicionales, se mantiene una conexión a la


base de datos por cada cliente final, esto es, si tenemos 100 clientes finales
tendremos 100 conexiones a la base de datos.

Esto es aceptable para aplicaciones con un número de clientes relativamente


pequeño, pero es inconveniente cuando la cantidad de clientes es grande, o
impredecible (como en aplicaciones en Internet), por varias razones:

7
 La carga al servidor de base de datos es mayor cuantas más conexiones
abiertas haya.
 En la mayoría de los DBMS se debe comprar una licencia de uso por cada
usuario conectado.
 No es óptimo, dado que la mayoría de las conexiones están sin hacer nada
una parte importante del tiempo.

La solución a estos problemas es permitir el compartir conexiones a la base de


datos entre los diferentes clientes de la aplicación, de modo de que existan menos
conexiones físicas a la base que clientes ejecutando la aplicación.

La idea general de un pool de conexiones es que cada vez que un cliente necesita
una conexión (esto es, cada vez que prepara un cursor, lo ejecuta, ejecuta una
sentencia directamente, etc.), se la solicita al pool. Esta conexión pertenece al
cliente hasta que de algún modo se determina que no la necesita más, y en ese
momento se le puede asignar la conexión a otro cliente.

Si un cliente necesita una conexión y no existe ninguna disponible, se queda


esperando hasta que alguna conexión se libere.

Otra ventaja es que las conexiones se mantienen abiertas, por lo que los clientes se
ahorran el tiempo de conexión al DBMS al iniciar la aplicación.

También podría gustarte