PDF de programación - Resolviendo el acceso a Base de Datos desde aplicaciones Web desarrolladas con J2EE: patrones de diseño

Accediendo a Base de Datos desde aplicaciones Web desarrolladas con

J2EE: patrones de diseño.

Carlos Presedo Varela, Nieves R. Brisaboa, Antonio Fariña

Laboratorio de Bases de Datos. Departamento de Computación.

Universidad de A Coruña. Campus de Elviña, s/n. 15071.

A Coruña. Spain

[email protected], {brisaboa, fari}@udc.es



Resumen



En este artículo se presenta un conjunto de patrones de diseño que facilitan el acceso a Bases de Datos
utilizando JDBC desde la capa modelo de aplicaciones Web desarrolladas según el patrón arquitectónico Model -
View - Controller. También se presenta una aplicación práctica, el portal Web de la Real Academia Gallega, en el
que se podrá ver la forma de utilizar estos patrones. Este portal ha sido desarrollado con el ánimo de suplir la
carencia de información existente en la Web sobre la academia gallega, al mismo tiempo que pretende difundir y
promover el uso del gallego en Internet. Este portal ha sido llevado a cabo completamente en el Laboratorio de Base
de Datos de la Universidad de A Coruña en colaboración con la Real Academia Gallega y en su desarrollo se han
aplicado variados patrones de diseño que han facilitado su comprensión y mantenimiento.

Palabras clave: patrones de diseño, J2EE, aplicaciones Web, acceso a Bases de Datos, patrón Data Access Object.



1. Introducción: Arquitectura general de las aplicaciones empresariales.

El rápido crecimiento de Internet en los últimos tiempos ha hecho que cada vez se demande más el
desarrollo de aplicaciones distribuidas que trabajen de forma transaccional conservando niveles de rapidez,
seguridad y escalabilidad aceptables. Para soportar la demanda de rendimiento de las nuevas aplicaciones Internet,
la arquitectura cliente/servidor en dos capas ha evolucionado a estructuras más complejas formadas por más capas y
en las cuales existe una separación clara de responsabilidades de cada una de las capas. En este contexto se suele
aplicar el patrón Model - View – Controller (MVC) [5], que permite separar la lógica de la aplicación de la vista y el
controlador, forzando así a desarrollar un diseño modular, mantenible y fácilmente escalable.


El patrón arquitectónico MVC hace una separación clara entre el modelo (lógica de negocio) y la vista
(interfaz gráfica), gracias a un controlador que los mantiene desacoplados y al mismo tiempo se encarga de
comunicarlos gestionando las peticiones del usuario (figura 1). De este modo se posibilita la reutilización de un
mismo modelo con distintas vistas (por ejemplo, una vista Web y una basada en ventanas) al mismo tiempo que se
pueden crear roles de trabajadores que faciliten la separación del trabajo entre equipos especializados.


La misión de cada una de las capas del patrón MVC es la siguiente:
Capa vista. Formada por el conjunto de interfaces de usuario, se encarga de interactuar con el usuario.

Usando J2EE [2, 3 y 8] esta capa suele implementarse mediante páginas JSP [1 y 9].

Capa controlador. Encargada de realizar la comunicación vista – modelo para que éste último atienda las
peticiones realizadas por los usuarios. Esta capa suele implementarse como uno o varios Servlets [10] al
trabajar con J2EE.

Capa modelo. En esta capa reside la lógica de la aplicación, independiente de la vista y del controlador.
Esta capa suele hacer uso de una Base de Datos para llevar a cabo las operaciones solicitadas por el

controlador y se suele implementar utilizando Enterprise Java Beans (EJB) [2 y 12] o usando clases que
acceden a Base de Datos a través de JDBC (Java DataBase Connectivity) [1 y 11].

Figura 1. Capas del patrón arquitectónico Model – View – Controller.

Para modelar la lógica de acceso a Base de Datos desde la capa modelo de aplicaciones Web desarrolladas
usando J2EE existen una serie de patrones de diseño que facilitan la labor de diseñadores y desarrolladores. Estos
patrones son el patrón Value Object [2, 3, 5, 6 y 7], que permite agrupar atributos procedentes de uno o varios
objetos del dominio, el patrón Data Access Object [2, 3, 5, 6 y 7], que permite desacoplar la lógica de negocio del
acceso a datos y el patrón Version Number [2 y 5], que permite gestionar los cambios en los datos cuando existen
vistas de actualización.



2. Descripción de patrones.

A continuación se describen los patrones de diseño utilizados para acceder a Base de Datos desde la capa



modelo en una arquitectura en tres capas usando tecnología JDBC.


2.1 Patrón Value Object.



Intención. Agrupar un conjunto de atributos procedentes de uno o varios objetos del dominio y facilitar el
intercambio de datos entre la capa modelo y la capa vista.

Estructura.

«interfaz»

DAO

«interfaz»

java.io.Serializable

VO

-atributos
+métodos get/set()



Figura 2. Estructura del patrón Value Object.



Capa Vista

Capa Controlador

Capa Modelo

Capa de entrada al modelo

Capa de acceso a datos

Base de Datos



Participantes.

o VO. El objeto valor.
o DAO. Son los encarg

ados de manejar la persistencia de los VO.

Colaboraciones. Un DAO devuelve VOs en sus métodos de búsqueda (find) y los recibe en sus métodos

creación (create) y actualización (update).

necesitamos representar un conjunto de atributos procedentes de uno o varios objetos del

Permite representar un conjunto de atributos procedentes de uno o varios objetos del

Aplicab



ilidad

.
o Cuando
dominio.

Consecuencias.

o Beneficio

s.

o Riesgos.


dominio.

In

formación obsoleta.

Variantes.



o Domain Value Object. Un Value Object es un Domain Value Object cuando sus atributos
o
o

corresponden a los de un objeto del dominio.
Custom Value Object. Se denominan así aque
uso, es decir, que sólo tienen los atributos necesarios para ese caso de uso.
Data Transfer HashMap. En una aplicación de tamaño medio puede exis
tir un gran número de
Value Objects, lo que genera un problema de mantenimiento. La solución es usar mapas para
almacenar pares <nombre-atributo, valor> en vez de las clases usadas hasta ahora, aunque tiene el
inconveniente de que es necesario establecer convenciones de nombrado.

llos Value Object que son específicos de un caso de



2.2 Patrón Data Access Object.



Intención. Desacoplar la lógica de negocio de la lógica de acceso a datos, de modo que se pueda cambiar la
fuente de datos fácilmente.

Estructura.

SessionFacade

<<use>>

<<use>>

DAOFactory

<<create>>

«interfaz»

DAO

DAOImpl1

DAOImpl2

DAOImpl3

<<adapts>>

<<adapts>>

<<adapts>>

Source A

Source B

Source C

Figura 3. Estructura del patrón Data Access Object.



Participantes.

o Session Facade. Abstrae las operaciones de negocio y para llevarlas a cabo utiliza los DAOs para
o
o
o
el interfaz anterior a una fuente de datos concreta.
o Source (Oracle, Informix, Sybase, PostgreSQL, SQL Server, BD O

obtener los datos. Gracias a la interfaz DAO no depende de la fuente de datos.
DAOFactory. Clase factoría encargada de crear una instancia del DAO del tipo
fuente de datos utilizada.
DAO. Abstrae las operaci
manipular datos.
DAOImpl. Adapta

rientada a Objetos, fichero
plano, servidor LDAP, etc.). Proporciona acceso y manipulación de datos mediante una API que
necesita ser adaptada.

ones sobre la fuente de datos, proporcionando una API para acceder y

adecuado según la

Colaboraciones. Un SessionFacade accede a los datos a través de un DAO, el cual adapta el API que

ofrece la fuente de datos.

Aplicabilidad.

o Para sepa
o Poder seleccionar el tipo de fuente de datos durante la instalación de una aplicación.

rar la lógica de negocio de la lógica de acceso a datos.

Consecuencias.
o Beneficio

s.

Independencia del vendedor de la fuente de datos.
Extensibilidad, ya que se facilita el cambio de fu

ente de datos. Los métodos del DAO
reciben y devuelven Value Objects, por lo que aunque se cambie la fuente de datos, el
resto de objetos que utilizan los DAOs no sufren modificaciones.

M

ás complejidad.

o Riesgos.



2.3 Patrón Version Number.



Intención. Evitar la actualización de un Value Object construido a partir de información obsoleta.

Problema. Supongamos que disponemos de una aplicación empresarial que permite tanto la consulta como
la actualización de datos. Dos administradores obtienen la misma información a partir de un Value Object y
uno de ellos la modifica. Sin actualizar la información que está visualizando, el otro administrador modifica
los datos y solicita grabarlos. En este caso, la segunda actualización sobrescribe a la primera.

Solución. El Value Object debería tener un atributo privado versionNumer de tipo entero1 y un método
get() para leer su valor. En consecuencia, la tabla subyacente que da soporte a la persistencia de este objeto
también debería presentar una columna versionNumber. Cada vez que se actualiza la información asociada
a este objeto en Base de Datos se debe realizar el siguiente proceso (ejecutado en la misma transacción):

o Leer de la Base de Datos el versionNumber del objeto.
o Si es igual al del Value Object, se incrementa este versionNumber y se actualiza el objeto.
o En otro caso se lanza una excepción.

Estructura.

Value Object

-versionNumber
+getVersionNumber() : int



Figura 4. Estructura del patrón Version Number.