3c. Patrones de Capa de Acceso a Repositorio

1
3c. Patrones de Capa de Acceso a Repositorio

• Gestión de Sistemas en Internet
• Universidad Antonio de Nebrija, 2003/04
• Justo N. Hidalgo Sanz

2
Índice

• Introducción
• Patrones
• Gateway (Data Gateway, RecordSet, Table Gateway)
• DataMapper
• Table Inheritance

3
Rol de la Capa

• Comunicación con las diferentes piezas que tienen
  información útil para la aplicación.
• Generalmente, lo más importante Bases de Datos,
  XML.

4
Problemas

• Las consultas a los repositorios son variopintas
• SQL-92
• SQL-99
• Optimizaciones del estándar según productos
  -Oracle, Sybase, Informix, -
• Xquery
• Accesos propietarios
• A los administradores del sistema les viene bien
  acceder a las consultas SQL directamente
• Y si están incrustadas en el código C, Java, ?

5
Conclusiones

• Separar el acceso SQL, Xquery, OQL, de la
  lógica de dominio, de manera que estén en clases
  separadas.
• Catálogo breve de patrones http//www.martinfowle
  r.com/eaaCatalog/

6
Patrón Gateway (I)

• http//www.martinfowler.com/eaaCatalog/gateway.htm
  l
• Idea básica tener una clase por tabla de la base
  de datos.
• De esta manera, la lógica de negocio no ha de
  saber ni SQL, ni Xquery, ese conocimiento queda
  encapsulado en las clases Gateway.

7
Patrón Gateway (y II)
8
Opciones del Gateway (I)

• Row Data Gateway
• Una instancia de la clase por cada fila devuelta
  por la consulta
• http//www.martinfowler.com/eaaCatalog/rowDataGate
  way.html

9
Opciones del Gateway (II)
10
Opciones del Gateway (III)

• Table Data Gateway
• Útil cuando se quiere utilizar un Record Set
  (http//www.martinfowler.com/eaaCatalog/recordSet.
  html)
• Una instancia por cada tabla
• http//www.martinfowler.com/eaaCatalog/tableDataGa
  teway.html

11
Opciones del Gateway (IV)

• Record Set

12
Opciones del Gateway (y V)
13
Patrón DataMapper (I)

• http//www.martinfowler.com/eaaCatalog/dataMapper.
  html
• Qué pasa cuando el modelo orientado a objetos
• es muy complejo,
• y hay que relacionarlo con el modelo relacional?
• Si cambia uno, modificar el otro puede ser muy
  complejo.

14
Patrón DataMapper (y II)

• Capa de SW que separa el modelo de objetos de la
  aplicación, de la base de datos.
• Responsabilidad transferir datos entre los dos,
  y aislarlos entre sí
• La aplicación no tiene que conocer el esquema de
  la base de datos
• ni viceversa -esto último ocurre siempre-.

15
Tratamiento de herencia

• El modelo de datos relacional no permite tratar
  la herencia directamente.
• Sin embargo, nuestro modelo de negocio sí es
  orientado a objetos.
• Cómo almacenar información objetual en tablas
  relacionales?

16
Single Table Inheritance

• Una tabla para almacenar todas las clases en una
  jerarquía

17
Concrete Table Inheritance

• Una tabla para cada clase concreta en una
  jerarquía.

18
Class Table Inheritance

• Una tabla para cada clase en la jerarquía

19
Bibliografía

• Patterns of Enterprise Application Architecture.
  Martin Fowler. Ed. Addison-Wesley