Data Source - Esteban Calabria

Data Source
Lic. Esteban Calabria
2007
Layer Data Source
Los sistemas raramente viven aislados
del mundo.
La responsabilidad de la capa Data
Source es manejar la comunicación del
nuestro sistema con otros.
Debido a su importancia en las
aplicaciones empresariales, nos
centraremos en la comunicación con el
Motor de la Base de Datos
Persistencia
Patrones de Persistencia
Los patrones que analizaremos son:
Patrones
Active Record
Patrones
Negocio-Persistencia
Persistencia
Gateway
Table Data Gateway
Row Data Gateway
DAO – Data Access Object
Data Mapper
Patrones Negocio-Persistencia
Active Record
Active Record
Un objeto que envuelve una fila en una tabla o
vista de la base de datos, encapsula el
acceso a la base de datos y agrega lógica de
negocios a esos datos
Active Record
Active Records
Un ejemplo de los active records en el
mundo J2EE son los beans que manejan
su propia persistencia conocidos como
Bean-Managed Persistence
http://java.sun.com/j2ee/tutorial/1_3fcs/doc/BMP.html
Patrones Persistencia
Table Data Gateway
Table Data Gateway
Un objeto que actúa como un gateway a una tabla
de una base de datos. Una instancia maneja
todas las filas de la tabla
Table Data Gateway
Contiene todos los SQL para acceder a
una tabla o vista.
Maneja los select, insert, update y delete.
El resto del sistema llama a los métodos
de la Table Data Gateway cada vez que
quiere acceder a la Base de Datos
Table Data Gateway
Es un esquema simple y fácil de entender.
Resulta una forma natural de encapsular
el accesos a la base de datos.
Trabaja bien en plataformas que estén
preparadas para trabajar con RecordSets.
Table Data Gateway
Si bien naturalmente se piensa tener un
Table Data Gateway por cada Tabla de
nuestra base de datos, se pueden
considerar tener un Table Data Gateway
para una vista, incuso para un query o
consulta a la base de datos específica.
En ese último caso habrá que considerar
como manejar los inserts y los updates.
Table Data Gateway
Un tema a considerar es que devuelven
los métodos e búsqueda en la Table
Data Gateway, por ejemplo:
Según
el entorno puede devolver un
RecordSet
Puede devolver uno o una colección de
Data Transfer Objects (ver DAO)
Puede devolver un Vector, una Lista o un
Map
Puede devolver un iterador
Puede devolver directamente objetos de
negocio
Table Data Gateway
Por ejemplo se puede usar con
Transaction Script, sobre todo si el
entorno con el que trabajamos posee un
buen manejo de los RecordSets.
Parece ser un patrón natural para trabajar
con Table Module.
Table Data Gateway
Algunas Ideas
Se
puede generar de forma simple por medio
de code generation un Table Data Gateway a
nuestra Base de Datos.
De esa forma ante un cambio de versión de
nuestra base de datos nos puede ayudar a
verificar que el código fuente de la versión
anterior siga funcionando
Table Data Gateway
Ventajas
Es
una forma natural, simple y fácil de
entender para encapsular el acceso a la base
de datos
Su simpleza.
Data Access Object
Data Access Object (DAO)
Un objeto que abstrae, encasula y maneja el
acceso a un origen de datos para almacenar y
recuperar datos del mismo
Data Access Object (DAO)
Data Access Object (DAO)
En esencia es un Table Gateway, pero lo
incluimos un apartado aparte pues.
Es
un patrón mas relacionado con el mundo
java, figura entre los Core J2EE Patterns.
Hay muchos artículos, bibliografías y/o
arquitecturas existentes que lo utilizan
refiriéndose a él con el nombre genérico de
DAO
Data Access Object (DAO)
BusinessObject (Capa de Negocios).
Es
el cliente que necesita los datos. Puede
ser un Domain Model o un Transaction
Script. Delega todas las operaciones de
recuperacion y persistencia de los datos al
DataAccessObject.
DataAccessObject
El
objeto que abstrae la implementacion
subyacente de acceso a datos de la capa
de negocios.
Data Access Object (DAO)
DataSource
Representa
la implementacion del origen de datos
que puede ser una base relaciona, un archivo xml, un
archivo plano, otro sistema, etc.
TransferObject
Es
DTO. que se usa para transmitir los datos entre
ambas capas ya sea para recuperar los datos o para
actualizar el Data Source
Data Access Object
Como se puede ver es un Table Data Gateway
orientado funcionar con Data Transfer Objects
en vez de con RecordSets.
Se pueden generar los DAO y los DTO
mediante alguna estrategia de Code
Generation.
Algunas implementaciones que he visto
devuelven directamente los objetos de negocio
con logica
Data Access Object
Se puede usar junto
con un Abstract
Factory y tener una
jerarquía de DAOs
Incluso se puede
aplicar Dependency
Inyecto e inyectar
los DAOs
Row Data Gateway
Row Data Gateway
Un objeto que actúa
como un gateway a
un registro de la
base de datos. Hay
una instancia por fila
Row Data Gateway
Un Row Data
Gateway actúa
como un objeto que
replica a un registro
de la base de datos,
donde cada columna
se transforma en un
campo
Cada
Row Data
Gateway contiene
la lógica de acceso
a la Base de Datos,
es decir, los insert,
update y delete.
Row Data Gateway
Cómo
manejamos la lógica para las
búsquedas?
Dónde ponemos los métodos que
transformen el resultado de un select en
un Row Data Gateway?
Las posibles opciones son:
Incluirlos
como métodos estáticos dentro
del Row Data Gateway
Implementarlos en objetos finders
separados
Row Data Gateway
Además de tener un Row Data Gateway que
replique un registro de una tabla de la base de
datos, se puede tener uno que replique un
registro correspondiente al resultado de un SQL.
En ese último caso hay que considerar como
manejar los updates en el caso de que se
soporten
Row Data Gateway
Particularmente funciona bien con Transaction
Script
La diferencia entre un Active Record y un Row
Data Gateway es que este último no contiene
lógica de negocios
Mientras que el Table Gateway presenta una
interfaz coarsed grained el Row Data Gateway
presenta una interfaz fine grained
Row Data Gateway
Idea
Una
posibilidad generar todos los Row Data
Gateway por medio de code generation
(generación automática de código mediante
una programa).
Data Mapper
Data Mapper
Una capa de Mappers que transportam los datos
entre los objetos y la base de datos
manteniendolos, al mismo tiempo,
independiente entre si y el mapper.
Data Mapper
Visibilidad
El
Mapper ve la base de datos y ve a los
objetos de negocio, ellos no ven al data
mapper
Cuando usarlo?
Este
patrón se usa para persistir un domain
model
Data Mapper
Las responsabilidades del Data Mapper
son:
Tranferir
datos bidirecionalmente entre la
representación en memoria de los objetos y la
base de datos
Desentender los objetos en memoria de la
base de datos subyasente, el SQL y el
esquema subyacente.
Data Mapper
Deseable
Cuando
se tiene un modelo complejos y se
desea aprovechar las capacidades de los
objetos para organizar los datos y el
comportamiento de la aplicación
Esto puede llevarnos a que el esquema relacional
de la base de datos u el esquema que definamos
de nuestro objetos difierane entre sí.
Data Mapper
Los objetos y las base de datos
relacionales tienen difetentes formas de
estructurar las relaciones.
Manejo
de las Colecciones en los objetos.
Manejo de la herencia en los objetos.
Manejo de las relaciones como claves
foraneas en la base de datos.
Patrones Adicionales
Patrones Adicionales
Unit Of Work
Identity Field
Identity Map
Lazy Load
Metadata Mapping
Metadata Mapping
Describe el mapeo del modelo de objetos
contra la base de datos en una serie de
archivos por ejemplo xml
Es la estrategia usada por diversos
frameworks de persistencia como el
hibernate
Explorando algunas alternativas
Explorando algunas alternativas
Active Record
Transaction Script -> Table Gateway
Transaction Script -> Row Data Gateway
Table Module -> Table Gateway
Domain Model -> Table Gateway
Domain Model -> Row Data Gateway
Domain Model -> Data Mapper
Domain Model -> Metadata Mapping
http://java.sun.com/blueprints/corej2eepatt
erns/Patterns/DataAccessObject.html
http://java.sun.com/blueprints/patterns/DA
O.html