Arquitectura de Aplicaciones Web - Capa de Acceso a Datos

Introducción

La capa de acceso a datos contiene la lógica principal de acceso y persistencia de datos dentro de nuestra aplicación Web. Dado a que las aplicaciones empresariales están centradas en los datos (data centric), la capa de acceso a datos tiene una importancia crucial dentro de la arquitectura de nuestra aplicación Web. La capa de acceso a datos tiene que soportar no solo el almacenamiento de datos, sino la recuperación de información de formas complejas y la concurrencia de múltiples usuarios accediendo a la información.

Componentes de la capa de acceso a datos

La capa de acceso a datos tiene dos tipos fundamentales de componentes:

Componentes de lógica de acceso a datos. Estos presentan una interfaz a la capa de negocio que abstrae de la forma en que se acceden a los datos almacenados, haciendo a la aplicación más fácil de configurar y mantener
Componentes utilitarios y auxiliares. Consisten en librerías especializadas o APIs que permiten acceder, manipular o transformar los datos dentro de los componentes de de lógica de acceso a datos. Por lo general son suministrados por el fabricante del gestor de base de datos (Oracle, IBM, etc.)

Factores a considerar al desarrollar la capa de acceso a datos

Cree un diseño general de su capa de acceso a datos

Identifique los requerimientos de las fuentes de datos (data sources)
Determine el enfoque de acceso a los datos
Elija como mapear estructuras de datos a los resultados de las fuentes de datos (data sources)
Determine como conectarse a las fuentes de datos
Elija la estrategia para tratar errores de conexión con las fuentes de datos

Diseñe sus componentes de acceso a datos

Enumere las fuentes de datos a las que va a acceder
Decida el método de acceso para cada fuente de datos
Determine que componentes auxiliares o librerías son necesarios para facilitar el acceso el acceso a los datos así como las tareas de desarrollo y mantenimiento
Estudie si puede aplicar patrones de diseño en el acceso a los datos (Table Data Gateway, Query Object, Repository, etc.)

Diseñe sus componentes auxiliares

Identifique que funcionalidades pueden moverse fuera de los componentes de acceso a datos y crear un componente auxiliar para su reutilización
Busque librerías de componentes auxiliares disponibles
Considere componentes auxiliares para solucionar problemas como conexiones, autenticación, monitorización o tratamiento de excepciones
Considere añadir logging a sus componentes auxiliares

Consideraciones de diseño de la capa de acceso a datos

Seleccione la tecnología adecuada de acceso a datos. La tecnología de acceso a datos depende del tipo y volumen de los datos que necesitamos. Determinadas tecnologías son mejores en determinados escenarios. Por ejemplo, la recuperación de miles de registros por una única clave y si no hay necesidad de consultas complejas, podría llevarnos a utilizar un gestor de base de datos NOSQL en vez de un gestor SQL relacional clásico.
Utilice la abstracción para implementar componentes de acceso a datos débilmente acoplados al sistema de gestión de base de datos. Esto nos permite no solo desarrollar cómodamente y mantener nuestra capa de acceso a datos, sino incluso migrar todos los datos de un gestor a otro con el mínimo o ningún impacto en nuestra aplicación Web
Considere la mapear los datos obtenidos en objetos o estructuras de datos que son más simples de procesar en la capa de negocio
Encapsule todas las funcionalidades de acceso a bases de datos dentro de la capa de acceso a datos. Esta capa tiene que ocultar a la capa de negocio todo lo relacionado con conexiones, mapeos y transformaciones básicas de datos, generar consultas, etc.
Decida como manejar las conexiones. Como regla, la capa de acceso a datos tiene que manejar todas las conexiones a todas las fuentes de datos requeridas por la aplicación. Estudie como almacenar y proteger acorde a sus requerimientos de seguridad, la información que describe a estas conexiones.
Determine como tratar las excepciones de datos. La capa de acceso a datos debe capturar todas las excepciones relacionadas con las fuentes de datos y las operaciones CRUD (Create, Read, Update & Delete – Crear, Leer, Actualizar y Borrar) relacionadas con la base de datos. Las excepciones producidas por los datos solo deben pasarse a la capa de negocio si afectan la funcionalidad o la respuesta de usuario de la aplicación
Considere los riesgos de seguridad. La capa de acceso a datos debe de protegerse contra mecanismos de ataque que traten de borrar, corromper, alterar los datos o tomar control de la fuente de datos.
Reducir el tráfico de datos siempre que sea posible.
Considere el desempeño y la escalabilidad de la base de datos. Estudie los límites de acceso a datos de su aplicación. Realice pruebas de estrés y pruebas de carga que permitan encontrar esos límites acorde a las capacidades del entorno de Producción de su instalación. Recuerde que lo que en un entorno de test o de desarrollo es factible en términos de concurrencia, volumen de datos o respuesta de usuario no tiene nada que ver en un entorno de Internet con diferentes conexiones a diferentes velocidades, cientos o miles de usuario accediendo al mismo tiempo y miles de MB o GB transfiriéndose entre los servidores y los clientes en navegador que ejecutan nuestra aplicación

Problemas comunes en el diseño de la capa de acceso a datos

Categoría	Problemas comunes
BLOB	Almacenamiento incorrecto de objetos binarios de gran tamaño como videos, fotos o archivos de datos en la base de datos en vez de en el sistema de archivos Uso incorrecto del tipo BLOB en la base de datos Búsqueda y manipulación de datos BLOB
Ejecución por lotes	Fallos al utilizar la ejecución por lotes para reducir el tráfico en la base de datos Tratamiento de los bloqueos cuando se ejecutan procesos por lotes durante mucho tiempo Fallo al elegir las ventanas horarias para tratar la base de datos con procesos por lotes
Conexiones	Configuración incorrecta del pool de conexiones Fallos a la hora de manejar timeouts de conexiones y desconexiones Ejecutar transacciones que abren múltiples conexiones Mantener las conexiones abiertas durante períodos de tiempo excesivos
Formato de datos	Elección del formato incorrecto para los datos Error al elegir el tipo de serialización No mapear objetos contra las tablas del gestor de base de datos
Tratamiento de excepciones/ errores	No tratar las excepciones de datos Fallo al no grabar en el log las excepciones críticas de acceso a datos
Consultas	Usar concatenación de cadenas a la hora de construir consultas Mezclar las consultas con la lógica de negocio No optimizar la base de datos para ejecutar consultas (no crear por ejemplo los índices necesarios o acceder por columnas que no son índice)
Procedimientos almacenados	No pasar correctamente los parámetros a los procedimientos almacenados Implementar lógica de negocio en procedimientos almacenados No considerar el impacto de sentencias SQL dinámicas en cuanto a rendimiento, seguridad y mantenimiento de la aplicación
Transacciones	Usar el nivel correcto de aislamiento Utilizar bloqueos exclusivos que pueden provocar contención y dead-locks Permitir que transacciones de larga duración bloqueen el acceso a los datos
Validación	Fallo al no validar los datos contra los tipos de campo No tratar valores tipo NULL No filtrar caracteres inválidos
XML	No considerar como tratar datos XML muy grandes Fallo al validar entradas XML utilizando esquemas