PDF de programación - 9. Taller de Formación.NET

9. Taller de Formación.NET

Ing. Gustavo Guimerans
A/C. Nicolás Sampietro
A/C. Emiliano Martínez

Capa de acceso a datos

1 Introducción

La capa que describe la agrupación lógica de las funcionalidades y componentes que ac-
ceden a los datos (fuentes de datos, como bases de datos relacionales o servicios web) en una
aplicación se conoce como la capa de datos (data layer).

Este documento está basado en la segunda edición del libro Mi-
crosoft Application Architecture Guide [1]. Su lectura brinda una
completa guía sobre el uso de las distintas tecnologías.

1.1 Descripción General

Esta capa provee acceso a la información dentro del sistema y datos expuestos en la red.

Expone interfaces genéricas que la capa de negocio puede consumir.

La capa de datos usualmente incluye:
• Data Access components: estos componentes abstraen la lógica requerida para acceder
a los almacenes de datos. Centralizan las funcionalidades comunes de acceso a datos con el
objetivo de lograr una aplicación más simple de configurar y mantener.

.

i

T
E
N
n
ó
c
a
m
r
o
F
e
d

r
e



l
l

a
T

554

• Service agents: cuando un componente de negocio necesita acceder a datos que provee
un servicio externo, es necesario implementar código. Los componentes que implementan
esta actividad son los service agents. Permiten aislar la diversidad de requerimientos que im-
ponen la llamada a estos servicios y brindan otros servicios como caching, soporte offline y
un mapeo entre el formato de quien expone el servicio y la aplicación.

2 Consideraciones generales de diseño

La capa de acceso a datos debe cumplir con los requerimientos de la aplicación: ser efi-
ciente y segura, fácil de mantener y extender cuando hay cambios en los requerimientos de
la capa de negocio. En este capítulo se describen los principales puntos generales a tener en
cuenta al momento de diseñar la capa de acceso a datos. Elegir el tipo adecuado de tecnología
depende de:

• el tipo de datos que se tengan que manejar,
• cómo se necesiten manipular. Abstraer. Implementar interfaces de acceso a datos con
bajo acoplamiento. Encapsular las funcionalidades de acceso a datos en la capa de acceso a
datos.

La capa debe:
• Ocultar detalles de acceso a la fuente de datos.
• Ser responsable de: manejar las conexiones, generar consultas, mapear entidades de la
aplicación a estructuras de datos. Decidir como mapear entidades de la aplicación a estruc-
turas de datos.

Dependerá básicamente del tipo de entidad que se use en la aplicación. Diseños comunes

siguen enfoques:

consolidadas.

• Patrones Domain Model Table Module.
• Frameworks Object/Relational Mapping (O/RM). Considerar estructuras de datos

T
a

l
l



e
r

d
e
F
o
r
m
a
c
ó
n
N
E
T

.

i

555

• Ej. Si se están exponiendo datos a través de servicios considerar Data Transfers Objects

(DTOs). Decidir cómo se manejarán las conexiones.

• La capa de acceso a datos deberá crear y manejar todas las conexiones a fuentes de datos
que requiera la aplicación. Es necesario elegir el método apropiado para almacenar y proteger
la información de conexión, eventualmente mediante secciones encriptadas de archivos de
configuración. Determinar cómo se manejarán las excepciones.

• La capa de acceso a datos deberá manejar las excepciones asociadas a operaciones
CRUD (Create, Read, Update and Delete) con las fuentes de datos. Considerar riesgos de
seguridad. Reducir tráfico “muchas idas y vueltas”.

• Considerar operaciones por lotes (batch) en simples sentencias SQL.
• Considerar los objetivos de escalabilidad y de performance.

3 Consideraciones especificas de diseño

Al momento de desarrollar el diseño hay varios problemas comunes a considerarse. Es-
tos problemas pueden categorizarse en aéreas especificas de diseño. Las aéreas donde más
problemas existen son: Procesamiento por lotes (batch), Binary Large Objects (BLOBs), Co-
nexiones, Formato de datos, Manejo de excepciones, Object Relational Mapping, Consultas,
Procedimientos almacenados (Stored Procedures).

• Stored Procedures vs. Dynamic SQL Transacciones Validaciones XML.
Por cada una de las aéreas, mencionadas anteriormente, existen varios puntos a conside-
rar. A continuación se mencionan algunos ejemplos asociados a tecnologías específicas. En
el capítulo 8 del libro [1] se describen cada uno de esos puntos.

3.1 Transacciones

• Microsoft SQL Server – cada SQL ejecuta como una transacción individual (auto-com-

mit transaction mode).

visto por el objeto TransactionScope.

• Para clases del namespace System.Transactions, considerar usar el modo implícito pro-

3.2 XML

• Considerar usar XML readers y writers para acceder a datos XML (especialmente cuan-
do sea mucho volumen). Si se desea interactuar con una base relacional, considerar usar
objetos que soporten esa funcionalidad tales como ADO.NET DataSet.

4 Consideraciones tecnológicas

Una de las decisiones más importantes a tomar, al momento de implementar un sistema,
pasa por la elección de la tecnología. La tecnología adecuada dependerá del tipo de aplicación
y los requerimientos. A continuación, se mencionan casos concretos que ayudan a tomar una
correcta decisión.

• Si se requiere soporte básico para consultas y parámetros, considerar directamente ob-

jetos ADO.NET.

.

i

T
E
N
n
ó
c
a
m
r
o
F
e
d

r
e



l
l

a
T

556

• Si se requiere soporte para escenarios de acceso a datos más complejos o simplificar el
código de acceso a datos, considerar utilizar el Enterprise Library Data Access Application
Block.

• Para aplicaciones Web data driven con páginas basadas en el modelo de datos de la base

de datos, considerar utilizar ASP.NET Dynamic Data.

• Para manipular datos con formato XML, considerar usar clases en el namespace System.

Xml, o Linq to XML (XLinq).

• Con interfaces ASP.NET, considerar DataReader para acceder a los datos con la máxi-

ma performance de renderizado. Ideales para operaciones read-only, forward-only.

• Para acceder a SQL Server, considerar ADO.NET la namespace SqlClient para maxi-

mizar performance.

• En SQL Server 2008, considerar FILESTREAM para una mayor flexibilidad en el alma-

cenamiento y para acceder a datos BLOB.

• Si se diseña una capa de negocio orientada a objetos en el patrón Domain Model, con-
siderar un framework Object/Relation Mapping (O/RM), tal como el ADO.NET Entity
Framework o el NHibernate framework de código libre.
5 Diseñando componentes de datos

En lo que resta de la lección se revisarán los pasos para el diseño de componentes aso-
ciados a datos. El primer paso es identificar las restricciones asociadas a los datos que se
accederán, lo cual ayudará a identificar la tecnología de acceso a datos adecuada. El siguiente
paso consiste en decidir la estrategia de mapeo y el enfoque de acceso a datos que se desea
implementar, esto consiste en identificar las entidades de negocio y la forma de represen-
tarlas. Luego se puede determinar cómo los componentes de acceso a datos se conectarán a
la fuente de datos. Finalmente, se determina la estrategia para manejo de excepciones en el
acceso a datos.

Es importante conocer con cuáles tecnologías se cuenta en la plataforma y para qué es-
cenarios es mejor una que otra. De esta manera, se pueden tomar otras decisiones necesarias
(por ejemplo: capacitación sobre determinada tecnología). Por tal motivo, se incluye en esta
guía una descripción de las tecnologías disponibles.

El sitio web de la Microsoft Developer Network (MSDN) [2] es el lugar indicado para
utilizar como referencia en todo momento de un proyecto en la plataforma Microsoft, prin-
cipalmente al momento de desarrollar, en particular para la plataforma .NET Framework, ya
que, por ejemplo, cuenta con documentación y ejemplos.

5.1 Paso 1 – Seleccionar la tecnología de acceso a datos

En este paso es que se hace necesario conocer las tecnologías disponibles en la plataforma
Microsoft, cuándo es recomendable su uso, escenarios comunes, así como sus ventajas y con-
sideraciones. A continuación se pretende llegar a cubrir estos puntos. Dada la importancia
que tienen hoy en día ADO.NET Entity Framework (EF) y LINQ se profundizará.

• ADO.NET Core. Brinda facilidades para recuperar, alterar y administrar información.
Incluye proveedores para bases de datos SQL Server, OLE DB, Open Database Connectivity
(ODBC), SQL Server Compact Edition y Oracle.

• ADO.NET Data Services Framework. Este framework permite exponer información
de cualquier fuente de datos Linq, típicamente un Entity Data Model, mediante REST sobre
HTTP. La información puede direccionarse mediante Uniform Resource Identifiers (URIs).

T
a

l
l



e
r

d
e
F
o
r
m
a
c
ó
n
N
E
T

.

i

557

Los servicios Web pueden configurarse para que retornen los datos con formato Atom y
JavaScript Object Notation (JSON).

• ADO.NET Entity Framework (EF): es un conjunto de tecnologías ADO.NET que
permiten el desarrollo de aplicaciones orientadas a datos. Brinda una experiencia de acceso
fuertemente tipada sobre base de datos relacionales. Mueve datos desde el modelo de alma-
cenamiento o lógico (las estructuras físicas de las tablas relacionales) al modelo conceptual
(que refleja los objetos de negocio). Introduce Entity Data Model a ADO.NET [4]. Soporta
LINQ to Entities. Permite que los programadores trabajen:

• con datos en forma de objetos y propiedades específicos del dominio; por ejemplo,
con clientes y direcciones, sin tener que pensar en las tablas y columnas de las bases en las
que se almacenan sino que consultan las entidades y relaciones en el modelo de dominio
(modelo conceptual),

• basados en EF para traducir esas operaciones en los comandos específicos del origen.
El modelo conceptual, el modelo de almacenamiento y las asignaciones entre los dos se
expresan en esquemas basados en XML y se definen en archivos de extensiones correspon-
dientes: El Conceptual Schema Definition Language (CSDL) define el mod