PDF de programación - ORM y JPA

ORM y JPA

Simon Pickin
Florina Almenárez Mendoza
Natividad Martínez Madrid
Pablo Basanta Val

Autores:



Dirección: Departamento de Ingeniería Telemática



Universidad Carlos III de Madrid
España

Versión:

1.0

Agradecimientos: Bill Burke, JBoss Group, Tal Cohen, IBM Haifa

Software de

Comunicaciones



© The Authors

1. Persistencia en Java:
Fallo en la adaptación objeto-relación y
mapeo objeto-relación (ORM)

Software de

Comunicaciones



© The Authors

2

La capa de persistencia

•

JDBC no es adaptación suficiente de un sistema DBMS
– Supone uso de RDBMS y SQL
– Incluso entre dos RDBMS diferentes, el SQL puede

cambiar

– El desarrollador Java puede no conocer (o no querer

conocer) SQL

– Demasiado bajo nivel

• Sobre el uso de una capa de persistencia

– Abstracción orientada a objeto de la base de datos

– Parte de una capa de negocio

– Entre la lógica de negocio y la capa de datos

– ¿Qué forma para una capa de persistencia?

Software de

Comunicaciones



© The Authors

El patrón Data Access Object (DAO)

• Patrón Data Access Object (DAO)

– Objeto que encapsula el acceso a la base de datos

• Separa la interfaz cliente de los mecanismos de acceso
• Provee un API genérica

– Mencionado en los “Core J2EE Patterns” de Sun
– Similar al patrón Fowler’s Table Data Gateway
– Utilizado a menudo con el patrón DTO

• Patrón Data Transfer Object (DTO)

– Objeto que encapsula datos de la base de datos
– similar al patrón Value Object de Sun (pero no al de

Fowler’s)

Software de

Comunicaciones



© The Authors

Consideración sobre la capa DAO

• Capa DAO de una aplicación

– Usualmente comprende muchos DAOs

– Algunos de los DAOs pueden encapsular

• Uniones de SQL
• Actualizaciones sobre múltiples tablas

• Solución de la capa DAO

– Demasiado pesada con algunos generadores de código

para DAO
• A no ser que la aplicación sea muy sencilla

– Metadatos usados para generación de código podrán ser

obtenidos de
• Un descriptor definido por el desarrollador
• Un esquema de la base de datos
•

ambos

Software de

Comunicaciones



© The Authors

Estrategias de implementación para DAO
(1/3)

• Codificar cada clase DAO explícitamente

– Más sencillo pero menos flexible

– Cambios en la DBMS a menudo implican cambios de la

implementación del DAO

• Usar una factoría DAO

– Patrón del método de factoría (Gamma et al.)

– Factorías de clase única

• Crean instancias de una clase DAO simple

– Factorías multi-clase

• Crean instancias de múltiples clases DAO

Software de

Comunicaciones



© The Authors

Estrategias de implementación para DAO
(2/3)

• Usar una factoría abstracta DAO

– Patrón factoría abstracta (Gamma et al.)

– Encapsula un conjunto de factorías DAO

• Uno para cada DBMS o tipo de DBMS

– Retorna un puntero a una factoría DAO

• Cada factoría implementa la misma interfaz abstracta

– Un cliente crea DAOs con la misma interfaz abstracta

• Con cualesquiera DBMS o tipos de DBMS

Software de

Comunicaciones



© The Authors

Estrategias de implementación para DAO
(3/3)

• Uso de clases genéricas para DAO

– Manejan diferentes DBMS del mismo tipo

– Los detalles dependientes de la fuente de datos son

cargados a partir del fichero de configuración
• Por ej. RDBMS: todo el SQL dependiente en el fichero de

configuración

• Uso de una factoría DAO abstracta y clases DAO

genéricas
– Retorna un puntero a un factoría DAO

– Un cliente utiliza una interfaz abstracta

• Cubre diferentes tipos de DBMS

– ... para crear DAOs genéricos

• Cubre diferentes DBMSs de un tipo dado

Software de

Comunicaciones



© The Authors

El patrón Active Record

• Patrón Active Record

– Puede ser visto como un patrón que combina DAO y

DTO

– Datos y comportamiento

– “Un objeto que envuelve una columna de una tabla en una
base de datos o vista, encapsula el acceso a la base de
datos y añade lógica de domino sobre ese dato.” Fowler

Software de

Comunicaciones



© The Authors

Active Record de Ruby on Rails

• Modelo del armazón MVC Ruby-on-Rails

• Patrón Active Record de Fowler

– + herencia + asociaciones de objetos

• El primero vía el patrón Single Table Inheritance
• El último vía un conjunto de macros

• Principios CoC y DRY

•

Impone
– Algunos aspectos en el esquema de la base de datos
– Algunas convenciones sobre el nombramiento

• Siguiendo las restricciones/convenciones RoR

– Desarrollo muy rápido

• No siguiendo restricciones/convenciones RoR

– Descarrila (derails) el desarrollo rápido

Software de

Comunicaciones



© The Authors

Desde el Active Record al ORM

• ORM puede ser visto como un active record, o similar, con
generación de código máxima y soporte añadido para
muchos de los siguientes mecanismos:

– Transacciones

– Políticas caché

– Integridad relacional

– Persistencia explicita

– Mapeo de transacciones

•

Asociaciones a objeto (1:1, 1:N, N:1, M:N)  restricciones de clave
foránea

– Mapeo flexible entre objetos y columnas de tabla:

• Un objeto simple representa una fila
• Múltiples objetos representan una fila
• Objetos sencillo representando múltiples columnas (uniones de

SQL)

– Herencia de relaciones entre objetos persistentes

– Carga perezosa

Software de

Comunicaciones



© The Authors

Fallo en la adaptación de impedancia de la
relación OR. Visión general (1/2)

• Situación inicial

– Lenguajes de programación, lenguajes de diseño:

•

usualmente OO

– Sistemas gestores de bases de datos (DBMS)

• Usualmente relacionales



=>muchos, muchos desarrollos/aplicaciones usan
ambos

• Base conceptual

– Modelo de objeto:

Identificar, encapsulación del estado + comportamiento,

•
• Herencia, polimorfismo

– Modelo relacional

• Relación, atributo, tupla,
•

valor relacional, variable relacional.



=> mapeo no-trivial: objeto relación  modelo relacional

Software de

Comunicaciones



© The Authors

Fallo en la adaptación de impedancia de la
relación OR. Visión general (2/2)

• Posibles soluciones

1. Evitar el problema

• Utilización de bases de datos XML
• Uso de lenguajes OO + DBMS OO
• Uso de lenguajes no OO + RDBMS
• Uso de lenguajes OO que incorporan conceptos relacionales +

RDBMS

2. Mapeo manual

• Codificar manualmente SQL usando herramientas relacionales

por ej. JDBC, ADO.NET

3. Utilizar una capa DAO

•
•

Aceptar las limitaciones mientras funcione para reducirlas
¡Saber cuando parar de reducirlas!

4. Usar un armazón ORM

•
•

Aceptar limitaciones mientras funcione para reducirlas
¡Saber cuando parar de reducirlas!

5. Mezclar y encajar

•

Por ejemplo, capa DAO parte de la cual usa ORM

Software de

Comunicaciones



© The Authors

Fallo en la adaptación impedancia de la
relación OR. Detalles (1/9)

• Cuestiones de gestión

– ¿Hasta qué punto debería el tipo de aplicación o la
aplicación escogida constreñir el esquema de la base de
datos?
• El modelo relacional puede ser usado por múltiples

aplicaciones

– También hay que tener cuidado con el caching de la base de

datos.

– Se tienen que manejar dos modelos separados pero

altamente acoplados
• Equipos diferentes pueden ser responsables de cada

modelo

• Problemas con la evolución / refactorización
• ¿Qué modelo va a ser considerado el principal?

Software de

Comunicaciones



© The Authors

Fallo en la adaptación impedancia de la
relación OR. Detalles (2/9)

• Asociaciones (también llamadas relaciones)

– Asociaciones que pueden tener las siguientes multiplicidades

• Nivel objeto: 1-1,1-N, N-1 y M-N; unidireccional y bidireccional
• Nivel relacional : 1-1 y asociaciones N-1 unidireccionales sólo


(claves foráneas no pueden apuntar a colecciones)

– El modelo relacional no puede modelar

•
•

Asociaciones 1-N unidireccionales
Asociaciones N-1 bidireccionales

– Modelo relacional estático incompleto

•
•

Asociaciones a nivel objeto de facto se mapean a claves + uniones
Para generar un modelo de dominio desde el modelo relacional

– Se debe de añadir información

– Asociaciones M-N se mapean a:

• Una relación para cada clase (R1, R2) + una relación de unión Rx
• Una asociación N-1 desde Rx a R1
• Una asociación M-1 desde Rx a R2

– Navegación de asociaciones M-N entre objetos persistentes

•

Implicaciones en el rendimiento

Software de

Comunicaciones



© The Authors

Fallo en la adaptación impedancia de la
relación OR. Detalles (3/9)

• Herencia

1. Tabla-por-clase (conteniendo sólo campos específicos de esa clase)

•
•

Patrón Class Table Inheritance de Fowler.
Problemas de eficiencia: por ejemplo preguntar el valor de un atributo de una
clase implica una unión sobre todas las relaciones que están mapeadas a
clases derivadas.

2. Tabla-por-clase-concreta (usualmente lo mismo que tabla por clase hoja)

•
•

•

Patrón Concrete Table Inheritance de Fowler.
Problemas de integridad, por ej. Unicidad de identificador definido en una clase
abstracta no está forzado sencillamente a lo largo del conjunto de relaciones
que están mapeadas a clases derivadas
No normalizado

3. Tabla-por-jerarquía-de-herencia

•
•
•
•
•

Patrón Single Table Inheritance de Fowler
Poco probable que esté normalizado
A menudo necesita un campo discriminador para identificar la clase mapeada
Tabla enrarecida: muchos campos pueden ser nulos
Los problemas de eficiencia se reducen si la mayoría de los campos heredan de
la clase base

4. Entre las opciones 1 y 3: tabla-por-clase-familia

Software de

Comunicaciones



© The Authors

Fallo en la adaptación impedancia de la
relació