Introducción

Automatizar procesos en una empresa es un tema recurrente hoy en día porque

es el camino para garantizar su crecimiento. Esta automatización lleva a las
empresas a recurrir a la implementación de servicios informáticos. Elaborar una
arquitectura para la implementación de un software es muy importante para
saber qué hacer para cumplir con las expectativas de las empresas. Una de las
arquitecturas usadas es la de -niveles orientada al dominio. Este patrón es una
extensión de N- Capas, pero centrado en el dominio y utilizada cuando el
comportamiento del negocio está sujeto a muchos cambios y evoluciones. En
este patrón se desenvuelven distintas capas y una de ellas es la Capa de
Persistencia de Datos, en esta podemos ver la capacidad de persistir de los
datos y su acceso a ellos además de ser importante porque hace posible trabajar
con varios gestores de datos sin necesidad de cambiar el código.
Definiciones

1. Capa
2. Persistencia
Según Pressman, los datos persisten sobreviven a la ejecución del
proceso que los creó. Los datos persistentes se almacenan en una base de
datos o archivos que pueden ser leídos o modificados por otros procesos
en un momento posterior.
En otras palabras, la persistencia se basa en almacenar los datos para
poder ser leídos o modificados a futuro.
3. Capa persistencia
Según Rodriguez, Márquez y Toro, en su investigación Gestión de la
evolución del software. El eterno problema de los legacy systems, la capa
de persistencia es construida específicamente para cada sistema. Permite
el acceso de aplicaciones desarrolladas con tecnología orientada a objeto
a datos organizados de cualquier forma (bases de datos relacionales,
archivos VSAM, etc.).
Por lo tanto, la capa de persistencia sirve de medio de comunicación
entre una aplicación orienta a objetos y datos persistentes.
Figurita
3.1. Partes
La capa de persistencia de datos suele incluir diferentes tipos de
componentes. A continuación, explicamos brevemente las
responsabilidades de cada tipo de elemento propuesto para esta
capa.
3.1.1. Repositorios
Son clases o componentes que encapsulan la lógica
requerida para acceder a las fuentes de datos requeridas por
la aplicación. Centralizan por lo tanto funcionalidad común de
acceso a datos de forma que la aplicación puede disponer de
un mejor mantenimiento y desacoplamiento ente la tecnología
con respeto a la lógica del Dominio.
3.1.2. Modelo de datos
 Este concepto existe a veces en la implementación de la
capa de persistencia para poder definir e incluso visualizar
gráficamente el modelo de datos entidad-relación de la
aplicación.
3.1.3. Persistencia
Es simplemente la capa de infraestructura/tecnología
utilizada internamente por los repositorios.
3.1.4. Agente servicios
Cuando un componente del dominio debe acceder a
datos proporcionados por un servicio distribuido externo (p.e.
un servicio-web), se debe implementar código que gestione la
semántica de comunicación con dicho servicio en particular.
3.2. Patrones
3.2.1. Patrón de diseño DAO
Se encarga de encapsular todo el acceso a una fuente
de datos utilizando la capa de acceso a datos. Asimismo, cada
objeto de negocio a ser persistido crea un DAO con la
información necesaria. Luego utiliza el objeto DAO para
obtener y guardar información del origen de datos.
Las ventajas de dicho patrón son; Centralización del
acceso a los datos en la nueva capa, mayor transparencia
debido a que los objetos de negocio no conocen el destino de
los datos, menor complejidad en objetos de negocio.
3.2.2. Active Record
Deposita la lógica sobre su persistencia dentro del
propio dominio del objeto. Sim embargo, uno de los
inconvenientes más grandes de este patrón viene de su
propia definición, al no separar conceptualmente el transporte
de datos de sus mecanismos de persistencia. Es una buena
elección para tablas que no tienen relación 1:1.
3.2.3. Table Data Gateway
Es una refinación del patrón active record, intenta
separar el propio transporte de datos de las operaciones
sobre el mantenimiento de estos. Muchos programadores
 esto supone una mejora, al delegar en un intermediario o
Gateway todo el trabajo de interacción con las bases de datos.
3.2.4. Data mapper
Este patrón tiene como objetivo separar las estructuras
de los objetos de las estructuras de los modelos relacionales
y realizar la transferencia de datos entre ambos. De esta
manera los objetos que consuman de los compontes de data
mapper, son ignorantes del esquema presente en la base de
datos y, por supuesto, no necesitan hacer uso de código SQL.
3.3. Pruebas
3.3.1. Pruebas de software
3.3.1.1. Pruebas erráticas
Una o más pruebas se comportan de forma
incorrecta, algunas veces las pruebas se ejecutan
de forma correcta y otras veces no. El principal
impacto de este tipo de comportamiento se debe al
tratamiento que sobre los mismo se tiene, puesto
que suelen ser ignoradas e internamente podrían
esconder algún defecto de código que no se trata.
3.3.1.2. Pruebas lentas
Las pruebas necesitan una gran cantidad de
tiempo para llevarse a cabo. Este síntoma, por lo
general, acaba provocando que los
desarrolladores no ejecuten las pruebas del
sistema cada vez que se realiza uno o varios
cambios, lo que reduce la cantidad del código al
estar exento de pruebas continuas sobre el mismo
y merma la productividad de las personas
encargadas de mantener y ejecutar estas pruebas.
3.3.1.3. Pruebas oscuras
En muchas ocasiones, debido a ciertos elementos
de inicialización de las pruebas y a los procesos de
limpieza o restablecimiento de datos iniciales el
 sentido real de la prueba queda obscurecido y no
se puede entender de un simple vistazo.
3.3.1.4. Pruebas irrepetibles
El comportamiento de una prueba varia si se
ejecuta inmediatamente a su finalización.
3.3.2. Pruebas de base de datos
3.3.2.1. Aislamiento de base de datos
Se proporcionado se usa una base de datos
diferente y separada del resto para cada uno de los
desarrolladores o probadores que estén pasando
pruebas que involucren a la capa de
infraestructura.
3.3.2.2. Deshacer los cambios en la finalización de cada
prueba
En el proceso de finalización de cada prueba
deshacer los cambios realizados. Para el caso de
base de daos mediante el uso de transacciones.
Esta alternativa tiene impacto en la velocidad de
ejecución de las pruebas.
3.3.2.3. Rehacer el conjunto de datos en la finalización de
cada prueba
Esta alternativa consiste en rehacer el conjunto de
datos al estado inicial de la prueba con el fin de que
la misma se pueda repetir inmediatamente.
Flujo – Actividades
Bibliografía
Ejemplo - Aplicaciones