to get the file

Desarrollo
de
Sistemas
de
Información
Tema
5.
Arquitectura
de
las
aplicaciones
con
acceso
a
BD
Marta
Elena
Zorrilla
Pantaleón
DPTO.
DE
MATEMÁTICAS,
ESTADÍSTICA
Y
COMPUTACIÓN
Este
tema
se
publica
bajo
Licencia:
CreaIve
Commons
BY‐NC‐SA
3.0
R EFERENCIAS
2
 
UC‐Marta
Zorrilla
Libros
  ScoO
W.
Ambler.
The
Design
of
a
Robust
Persistence
Layer
For
RelaIonal
Databases.
2005
hOp://www.ambysoZ.com/
downloads/persistenceLayer.pdf
  Clinton
Begin,
Brandon
Goodin,
Larry
Meadors.
iBaIs
in
acIon.
New
York:
Manning,
cop.
2007.
  César
de
la
Torre
et
al.
Guía
de
Arquitectura
N‐Capas
DDD
.NET
4.0.
Krassis
Press,
2011
R EFERENCIAS
3
 
Recursos
web
 
 
 
ComparaIva
Frameworks:
hOp://crowdranking.com/crowdrankings/t420g0‐‐best‐java‐
persistence‐frameworks
 
Data
Skills
for
Agile
SoZware
Developer
hOp://www.agiledata.org/essays/developerSkills.html
 
EncapsulaIng
Database
Access:
An
Agile
"Best"
PracIce
hOp://www.agiledata.org/essays/implementaIonStrategies.html
ScoO
Ambler's
ArIcles
and
Other
WriIngs
hOp://www.ambysoZ.com/onlineWriIngs.html
Comparison
and
Benchmarks
on
ORMBaOle.NET
hOp://ormeter.net/
 
 
UC‐Marta
Zorrilla
iBaIs
hOp://ibaIs.apache.org/
Hibernate
hOp://www.hibernate.org/
I NTRODUCCIÓN
4
UC‐Marta
Zorrilla
 
Mayoritariamente,
los
Sistemas
de
Información
hacen
uso
de
bases
de
datos
relacionales
para
la
persistencia
de
sus
datos.
En
menor
medida
se
usan
BD
orientadas
a
objeto
y/u
Objeto‐relacionales.
Y
está
tomando
relevancia
las
BD
XML,
como
consecuencia
del
intercambio
de
datos
y
estándares
de
la
industria.
 
SQL,
estándar
desde
1987,
es
el
lenguaje
de
interrogación
y
definición
ampliamente
adoptado.
Ha
sido
extendido
para
abordar
el
modelado
de
los
datos
objetual
(OR)
y
semi‐
estruturado
(XML).
En
vigor,
estándar
SQL:2008.
 
Limitaciones:
sólo
una
parte
de
SQL
es
realmente
estándar
cuando
trabajas
con
disIntos
gestores
de
BD
 
A
favor:
declaraIvo,
potente,
ampliamente
uIlizado
I NTRODUCCIÓN
5
 
Por
otra
parte,
los
sistemas
de
información
se
ven
muy
afectados
por
los
cambios
normaIvos
y
organizaIvos
de
las
corporaciones,
lo
que
conlleva
a
cambios
en
los
requisitos
y
conInuas
adaptaciones
en
el
soZware.
 
Paralelamente
las
tecnologías
no
paran
de
avanzar
y
de
proponer
gran
canIdad
de
alternaIvas
que
permiten
construir
aplicaciones,
que
siguiendo
una
arquitectura
modular,
se
adapten
muy
bien
a
diferentes
escenarios.
 
¿Cómo
abordarlo?
 
UC‐Marta
Zorrilla
Analicemos
la
historia
R EVISIÓN
6
Ges=ón
de
datos
Ges=ón
de
datos
Ges=ón
de
datos
Ges=ón
de
datos
Procesamiento
Procesamiento
Procesamiento
Procesamiento
Presentación
Presentación
HISTÓRICA
Ges=ón
de
datos
Ges=ón
de
datos
Persistencia
Procesamiento
Presentación
UC‐Marta
Zorrilla
Presentación
Procesamiento
Procesamiento
Presentación
Presentación
Presentación
Desde
los
años
80
hasta
la
actualidad
la
arquitectura
de
las
aplicaciones
se
ha
ido
modificando
pasando
desde
una
arquitectura
centralizada
(todo
en
el
host)
a
una
distribuida,
en
el
que
se
reparte
el
aplicaIvo
en
varias
máquinas
(cliente
y
servidores)
aprovechando
así
las
capacidades
gráficas
y
de
cómputo
de
cada
Ipo
de
equipo
L AYERS
7
UC‐Marta
Zorrilla
AND
T IERS
 
Es
importante
disInguir
los
conceptos
de
“Capas”
(Layers)
y
“Niveles”
(Tiers)
 
Las
Capas
(Layers)
se
ocupan
de
la
división
lógica
de
los
componentes
que
consItuyen
el
soZware,
y
no
Ienen
en
cuenta
dónde
estará
ubicados
vsicamente.
 
Los
Niveles
(Tiers)
se
refieren
a
los
disIntos
equipos
en
donde
los
componentes
soZware
se
desplegarán.
 
Ambos
usan
nombres
similares
(presentación,
proceso/
servicio,
negocio
y
datos),
pero
es
importante
no
confundirlos.
C ARACTERÍSTICAS
8
 
 
UC‐Marta
Zorrilla
DE LAS APLICACIONES
Aplicaciones
centralizadas
(1
Ier)
(desde
1970
a
..):
 
Interfaces
orientadas
a
texto
 
Desarrollado
principalmente
con
Cobol,
y
lenguajes
4GL
que
embebían
el
lenguaje
SQL
del
gestor
de
BD
(Informix‐4GL,
Oracle,
etc.)
 
Aplicaciones
eficientes,
ágiles,
pero
poco
usables
2
Ier
(1990‐95):
 
Interfaces
gráficas
en
cliente
con
capacidad
de
procesamiento.
 
Se
basaba
en
la
invocación
de
instrucciones
SQL
desde
cliente.
A
veces
estas
instrucciones
eran
procedimientos
almacenados
que,
incluían
no
sólo
el
SQL
sino
también
lógica
de
negocio.
Se
llevaba
todo
el
cómputo
al
servidor.
 
Recordemos
que
los
procedimientos
almacenados
siguen
lenguaje
procedimental
y
no
declaraIvo.
Impide
portabilidad.
 
Las
aplicaciones
presentaban
problemas
de
escalabilidad
y
rendimiento
y
su
despliegue
era
una
locura
“el
infierno
de
las
dlls”
 
Herramientas:
VB,
PowerBuilder,
Oracle
Forms,…
con
API
ODBC.
Prob.
Con
el
pool
de
conexiones
C ARACTERÍSTICAS
9
 
3‐Ier
o
N‐Ier
(1994‐…):
 
 
 
 
 
 
UC‐Marta
Zorrilla
DE LAS APLICACIONES
Interfaces
“thin”
y
“thick”
Surgen
con
la
llegada
de
Internet
y
el
protocolo
hOp.
Se
divide
la
aplicación
en
capa
de
presentación,
de
negocio
y
de
datos.
Los
procedimientos
almacenados
se
llevan
a
la
capa
de
negocios
(como
llamadas
a
procedimientos
remotos)
donde
se
mejora
el
rendimiento
con
una
gesIón
más
opImizada
del
pool
de
conexiones
y
los
recursos
de
gestor.
Estos
son
muy
eficientes
en
cuanto
a
que
manipulan
la
información
que
está
en
el
propio
gestor
pero
son
más
divciles
de
escribir
y
probar
pues
no
están
ligados
a
las
metodologías
soZware
actuales
(orientadas
a
objetos
vistos
desde
la
perspecIva
de
aplicación).
Algunos
gestores
ya
permiten
la
programación
de
procedimientos
en
java
o
C#
pero
es
un
parche
que
solo
resuelve
la
portabilidad
de
la
BD.
C ARACTERÍSTICAS
10
 
3‐Ier
o
N‐Ier
(1994‐…):
 
 
UC‐Marta
Zorrilla
DE LAS APLICACIONES
Inline
SQL:
a
conInuación
aparecieron
lenguajes
como
SQLJ
(estandarizado
en
SQL2003)
que
embebía
instrucciones
SQL
en
java
pero
no
ha
sido
muy
uIlizado.
 
SQL
no
estándar
y,
por
tanto,
no
se
puede
hacer
un
parser
general
 
Necesidad
de
un
precompilador
 
Dificultad
para
integrarlo
en
los
IDE
de
desarrollo
Dynamic
SQL:
resuelve
el
problema
del
precompilador,
escribiendo
el
SQL
en
un
string.
Esto
requiere
una
API
para
configurar
los
parámetros
y
recuperar
los
datos
(
JDBC,
ADO
Net)
 
Ventaja:
flexibilidad
para
construir
dinámicamente
las
SQLs
 
Inconveniente:
mucho
código
repeIIvo
cada
vez
que
quieres
ejecutar
una
consulta.
Además
el
SQL
puede
venir
concatenado
lo
que
resulta
divcil
de
leer
y
mantener
E J . SQLJ
11
SQLJ
estándar
estático
JDBC
no estándar
dinámico
UC‐Marta
Zorrilla
Y
JDBC
#sql [ctx] {
SELECT MAX(SALARY), AVG(SALARY)
INTO :maxSalary, :avgSalary
FROM DSN8710.EMP
};
PreparedStatement stmt = conn.prepareStatement(
"SELECT MAX(SALARY), AVG(SALARY)“ +
" FROM DSN8710.EMP");
rs = stmt.executeQuery();
if (!rs.next()) { // Error -- no rows found }
maxSalary = rs.getBigDecimal(1);
avgSalary = rs.getBigDecimal(2);
if (rs.next()) { // Error -- more than one row found }
rs.close();
stmt.close();
C ARACTERÍSTICAS
12
 
3‐Ier
o
N‐Ier
(1994‐…):
 
 
 
 
Actualmente,
la
solución
adoptada
es
diseñar
una
capa
que
realice
el
mapeo
objeto‐relacional.
Sus
siglas
ORM
se
refieren
al
mapeo
de
objetos
del
soZware
de
aplicación
a
relaciones
o
tupas
del
modelo
relacional
para
su
persistencia
y
recuperación
posterior.
Su
uso
se
exIende
también
a
otras
tecnologías
no
relacionales
(BD
XML,
ficheros,
etc.)
Ventajas:
 
 
UC‐Marta
Zorrilla
DE LAS APLICACIONES
Muchas
herramientas
ORM
generan
código
SQL
directamente,
realizan
convenientemente
la
gesIón
de
transacciones,
ofrecen
posibilidades
de
caching
Algunas,
están
diseñadas
con
ciertas
reglas
que
obligan
a
que
la
BD
está
normalizada
perfectamente,
lo
que
influye
negaIvamente
en
su
rendimiento.
Muchas
empresas
construyen
su
propio
ORM.
13
UC‐Marta
Zorrilla
A RQUITECTURA L ÓGICA
 
User‐interface
classes
should
not
directly
access
your
persistence
mechanisms.
 
Domain
classes
should
not
directly
access
your
persistence
mechanisms.
 
The
class‐type
architecture
is
orthogonal
to
your
hardware/network
architecture
A RQUITECTURA F ÍSICA
14
Class
type
Stand
Alone
Fat‐client
Thin
–client
N‐=er
User
Interface
Client
Client
Client
Client
Controller/
process
Client
Client
Server
ApplicaIon
server
Domain/
business
Client
Client
Server
ApplicaIon
server
Persistence
Client
Server
Server
Database
Server
System
Client
All
machines
All
machines
All
machines
1
Ier‐
c/s
UC‐Marta
Zorrilla
2
Ier‐
c/s
3
Ier‐
c/s
N ECESIDAD
15
UC‐Marta
Zorrilla
DE LA
C APA
DE
P ERSISTENCIA
 
Persistencia
es
la
capacidad
de
un
lenguaje
de
programación
o
entorno
de
desarrollo
de
programación
para,
almacenar
y
recuperar
el
estado
de
los
objetos
de
forma
que
sobrevivan
a
los
procesos
que
los
manipulan.
 
¿Es
necesaria?
Si,
debido
al
desajuste
de
impedancia
entre
el
modelo
de
datos
de
los
paradigmas
de
programación
orientados
a
objetos
y
el
de
los
gestores
de
bases
de
datos
(relacionales,
OR,
xml,
etc).
Para
el
caso
relacional,
 
Modelo
de
objetos
(objetos
con
atributos,
métodos
y
relaciones
con
otros
objetos)
debe
descomponerse
en
varias
tablas
(de
acuerdo
a
las
relaciones
1:N
y
N:M)
para
almacenarse
y
su
recuperación
requiere
varios
JOINs
 
En
los
gestores
relacionales
el
acceso
es
asociaIvo,
esto
es,
basado
en
el
contenido
(valor
de
clave)
y
no
navegacional,
basado
en
el
movimiento
entre
registros
individuales.
 
Los
gestores
provee
Ipos
de
datos
que
no
Ienen
los
lenguajes
de
programación
OO
(
p.
ej.
Interval,
Date).
R EQUISITOS
16
C UMPLIR
 
La
capa
de
persistencia
encapsula
el
comportamiento
necesario
para
escribir,
recuperar,
actualizar
y
borrar
objetos
(de
la
aplicación
soZware)
a/desde
el
gestor
de
almacenamiento
persistente
(relacional,
XML,
ficheros,
etc.).
 
Esta
debe
soportar,
de
acuerdo
a
ScoO
Ambler
(2005):
 
 
 
 
 
 
UC‐Marta
Zorrilla
A
Diferentes
mecanismos
de
persistencia
(relacional,
XML,
ficheros,
etc.).
Encapsulación
completa:
no
debe
ser
necesario
escribir
ninguna
línea
de
código
que
acceda
al
gestor
de
persistencia,
deben
ser
suficiente
los
métodos
definidos
en
la
capa
de
persistencia
Acciones
sobre
varios
objetos
al
Iempo
(borrar
varios
objetos
o
consultarlos,
etc.)
Transacciones
simples
y
anidadas
(todo
o
nada
o
con
commit
parcial)
Extensibilidad:
fácil
para
susItuir
los
mecanismos
de
persistencia
existentes
y
poder
incorporar
nuevas
caracterísIcas
IdenIdad
de
objetos
persistentes:
la
capa
de
persistencia
debe
asociar
un
idenIficador
a
cada
objeto
persistente
que
sirva
para
localizar
de
forma
unívoca
el
objeto
guardado
en
el
gestor
de
persistencia
R EQUISITOS
17
 
UC‐Marta
Zorrilla
A
C UMPLIR
Esta
debe
soportar
(cont.):
 
Cursores:
debe
poder
recuperar
el
número
de
objetos
que
se
le
pidan
y
evitar
el
manejo
de
volúmenes
grandes
de
datos
 
Proxies:
complementa
al
cursor,
un
objeto
que
representa
a
otro
pero
sin
traerlo
a
memoria
hasta
que
se
solicite
expresamente
 
MúlIples
arquitecturas:
debe
poder
adaptarse
a
cualquier
Ipo
de
arquitectura
(centralizada,
c/s,
n‐capas)
 
Diferentes
gestores:
si
se
produce
un
cambio
de
gestor
las
aplicaciones
no
se
ven
afectadas
 
MúlIples
conexiones:
debe
permiIr
abrir
conexiones
a
diferentes
bases
de
datos
dentro
de
una
misma
aplicación
 
Suporte
a
drivers
naIvos
y
no
naIvos
(JDBC,
ODBC,…)
 
Consultas
SQL:
aunque
se
debe
evitar
el
SQL
en
el
código
OO,
en
ocasiones
es
necesario
por
rendimiento
y
debe
permiIrse.
18
UC‐Marta
Zorrilla
M ECANISMOS
DE
P ERSISTENCIA
ScoO
Ambler,
2005
M ECANISMOS
19
UC‐Marta
Zorrilla
DE
P ERSISTENCIA
 
Acceso
directo
a
BD.
Implica
el
uso
directo
de
la
BD
haciendo
uso
de
una
interfaz
estandarizada
y
un
lenguaje
de
consulta
soportado
por
el
gestor.
No
existe
capa
de
persistencia
entre
el
gestor
y
la
aplicación.
 
Mapeadores:
mecanismos
que
se
basan
en
la
traducción
bidireccional
entre
los
datos
encapsulados
en
los
objetos
de
la
lógica
de
un
Sistema
OO
y
el
modelo
de
datos
de
la
fuente
de
datos.
El
mapeador
es
el
encargado
de
realizar
la
conversión
entre
paradigmas,
bien
de
forma
manual
o
automáIca.
 
Generadores
de
código:
usar
herramientas
generadores
de
código
basadas
en
patrones
para
resolver
la
persistencia,
centrándose
el
desarrollador
en
el
código
que
resuelve
la
lógica
de
negocio.
M ECANISMOS
20
P ERSISTENCIA
 
Orientación
a
aspectos:
paradigma
orientado
a
modularizar
las
aplicaciones
en
determinados
conceptos,
uno
de
ellos
es
la
persistencia
 
Lenguajes
orientados
a
objetos:
uIlizar
funcionalidades
de
persistencia
provistas
por
el
propio
lenguaje
de
programación
evitando
la
inclusión
de
frameworks.
 
 
UC‐Marta
Zorrilla
DE
Librerías
estándar
usando
técnicas
como
la
serialización
de
objetos
(no
gesIona
transacciones
ni
incorpora
lenguajes
de
consulta);
lenguajes
que
provean
persistencia
o
usando
lenguajes
que
integren
un
lenguaje
de
consulta
sobre
el
sistema
persistente
como
OQL,
HQL.
Prevalencia,
técnica
para
hacer
persistentes
los
datos
que
están
en
memoria
ppal.
usando
técnicas
de
serialización.
Manejan
transacciones
y
pueden
recuperar
un
estado
estable
si
cae
el
sistema.
F RAMEWORKS
21
UC‐Marta
Zorrilla
DE
P ERSISTENCIA
 
Framework
es
un
conjunto
de
librerías
o
clases
que
proporciona
una
infraestuctura
que
actúa
de
soporte
para
desarrollar
aplicaciones.
Esto
es,
es
un
esquema
o
patrón
para
el
desarrollo
de
una
aplicación
completa
o
de
una
parte
específica
de
la
misma.
 
Los
frameworks,
a
diferencia
de
un
conjunto
de
librerías,
ofrecen
una
serie
de
servicios
para
implementar
el
artefacto
soZware
ocultando
su
complejidad
al
programador
y
ahorrando
Iempo
de
programación.
Por
otra
parte,
está
más
limitado
un
cambio
en
su
funcionalidad.
 
Framework
de
persistencia
es
un
marco
de
trabajo
que
se
sitúa
entre
la
lógica
de
negocio
y
la
capa
de
base
de
datos,
abstrayendo
uno
del
otro.
F RAMEWORKS
22
 
OpenJPA
is
an
open
source
implementaIon
of
the
Java
Persistence
API
specificaIon.
It
is
an
object‐relaIonal
mapping
(ORM)
soluIon
for
the
Java
language,
which
simplifies
storing
objects
in
databases
EclipseLink
 
UC‐Marta
Zorrilla
Hibernate
is
an
object‐relaIonal
mapping
(ORM)
library
for
the
Java
language,
providing
a
framework
for
mapping
an
object‐oriented
domain
model
to
a
tradiIonal
relaIonal
database.
OpenJPA:
 
 
MyBa=s
is
a
persistence
framework
available
for
Java
and
.NET
that
couples
objects
with
stored
procedures
or
SQL
statements
using
an
XML
descriptor
or
annotaIons.
Hibernate:
 
 
JAVA
IbaIs:
 
 
PARA
EclipseLink
is
the
open
source
Eclipse
Persistence
Services
Project
from
the
Eclipse
FoundaIon.
The
soZware
provides
an
extensible
framework
that
allows
Java
developers
to
interact
with
various
data
services,
including
databases,
web
services,
Object
XML
mapping
(OXM),
and
Enterprise
InformaIon
Systems
(EIS).
EclipseLink
supports
a
number
of
persistence
standards
O TROS
23
  Torque
  JDO
Genie
  Castor
  LiDO
  OJB
  Cayenne
  JDBM
  JDO
Toolkit
  FronIerSuite
  PBeans
  Jrelay
  Simple
ORM
  IntelliBO
  JULP
(Java
Ultra‐Lite
Persistence)
  Smyle
  Speedo
  XORM
  JDBCPersistence
UC‐Marta
Zorrilla
FRAMEWORKS PARA
  kodoJDO
  ….
J AVA
O TROS
24
  Sql
client
  EnIty
Framework
  LINQ
to
SQL
  BTLToolkit
  DataObjects.Net
  LinqConnect
  Nhibernate
  OpenAccesss
  Etc….
UC‐Marta
Zorrilla
FRAMEWORKS PARA
N ET
I B ATIS
25
 
iBaIs
es
un
framework
que
facilita
el
diseño
de
la
capa
de
persistencia
uIlizada
en
las
aplicaciones
Java
para
acceder
a
nuestro
repositorio
de
datos.
 
iBaIs
une
los
Objetos
con
las
sentencias
SQL
mediante
un
descriptor
XML.
iBaIs
necesita
uno
o
más
ficheros
con
las
sentencias
SQL
que
usará
el
programa
 
 
UC‐Marta
Zorrilla
IbaIs
necesita
un
fichero
de
configuración
en
XML
donde
se
indiquen
los
parámetros
de
conexión
a
la
base
de
datos
y
los
ficheros
de
mapeo
XML
H IBERNATE
26
UC‐Marta
Zorrilla
 
Hibernate
es
una
herramienta
de
Mapeo
objeto‐relacional
para
la
plataforma
Java
(y
disponible
también
para
.Net
con
el
nombre
de
NHibernate)
que
facilita
el
mapeo
de
atributos
entre
una
base
de
datos
relacional
tradicional
y
el
modelo
de
objetos
de
una
aplicación,
mediante
archivos
declaraIvos
(XML)
que
permiten
establecer
estas
relaciones.
 
Hibernate
no
requiere
conocer
el
modelo
de
datos
al
cual
se
accede.
Se
Iene
una
aplicación
Orientada
a
Objetos
y
él
mapea
el
diseño
OO
en
una
capa
de
persistencia.
 
La
mayor
diferencia
entre
Hibernate
e
iBATIS
proviene
del
hecho
de
que
el
úlImo
basa
su
funcionamiento
en
el
mapeo
de
sentencias
SQL
que
se
incluyen
en
ficheros
XML.
Eso
significa
que,
al
contrario
que
Hibernate,
requiere
conocimiento
de
SQL
por
parte
del
programador.
Por
otra
parte,
permite
la
opImización
de
las
consultas,
ya
sea
con
lenguaje
estándar
o
con
SQL
propietario
del
motor
de
base
de
datos
uIlizado.
Con
iBATIS,
siempre
se
sabe
lo
que
se
está
ejecutando
en
la
base
de
datos
y
permite
generar
consultas
dinámicas
muy
potentes.
H IBERNATE
27
UC‐Marta
Zorrilla
VS IBATIS
 
Hibernate
facilita
el
desarrollo
al
no
tener
por
que
tener
conocimiento
alguno
acerca
de
SQL,
pero
se
desaconseja
para
desarrollos
en
los
que
la
definición
del
modelo
de
datos
está
ya
definido
o
si
las
relaciones
en
el
modelo
de
datos
van
a
ser
complejas.
 
Por
otra
parte,
Hibernate
al
uIlizar
su
propio
lenguaje
de
consulta
de
datos,
lo
convierte
en
mulImotor
de
base
de
datos.
 
IbaIs
soporta
la
posibilidad
de
almacenar
consultas
en
la
caché
(usa
OpenSymphony
Cache)
y
pool
de
conexiones
(usa
Yacarta).
 
En
definiIva,
Hibernate
separa
más
la
capa
de
negocio
y
persistencia
que
IbaIs
en
la
que
el
desarrollador
“define”
el
enlace
(menos
nivel
de
abstracción).
 
Usaremos
IbaIs
en
las
prácIcas.