Actualizado el 2 de Mayo del 2021 (Publicado el 1 de Junio del 2017)
2.145 visualizaciones desde el 1 de Junio del 2017
1.009,0 KB
64 paginas
Creado hace 12a (07/09/2012)
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ó
Comentarios de: ORM y JPA (0)
No hay comentarios