Introducción al acceso a datos con ADO.NET

Cuando desarrolle aplicaciones con ADO.NET, contará con diferentes requisitos para trabajar con datos. En algunos casos, puede que simplemente desee mostrar datos en un formulario. En otros casos, quizá necesite idear un modo de compartir información con otra compañía.

Independientemente de lo que haga con los datos, hay algunos conceptos fundamentales que debe comprender acerca del trato de los datos en ADO.NET. Es posible que nunca necesite saber algunas cosas sobre el control de datos (por ejemplo, probablemente, nunca necesite editar directamente un archivo XML que contenga datos), pero sí es muy útil comprender la arquitectura de datos en ADO.NET, cuáles son los componentes principales y cómo encajan las piezas.

Esta introducción presenta información general de alto nivel sobre estos conceptos importantes. El tema omite deliberadamente muchos detalles — por ejemplo, hay mucha más información acerca de los conjuntos de datos que lo que se menciona aquí — para poder presentar de forma sencilla las ideas en las que se basa la integración de datos en ADO.NET.

Nota   Cuando implante una aplicación que incluya componentes de acceso a datos de Visual Studio, asegúrese de que el usuario que instale la aplicación tiene la versión 2,7 o una posterior de Microsoft Data Access Components (MDAC). Para obtener más información, vea Agregar una condición de inicio para Microsoft Data Access Components.

ADO.NET no depende de conexiones continuamente activas

En las aplicaciones tradicionales cliente/servidor, los componentes establecen una conexión con una base de datos y la mantienen abierta mientras la aplicación está en funcionamiento. Por diferentes razones, este enfoque no resulta práctico en muchas aplicaciones:

• Las conexiones abiertas de base de datos consumen valiosos recursos del sistema. En la mayoría de los casos, las bases de datos sólo pueden mantener un pequeño número de conexiones concurrentes. La sobrecarga que supone mantener estas conexiones reduce el rendimiento general de la aplicación.
• Por la misma razón, las aplicaciones que necesitan una conexión de base de datos abierta resultan extremadamente difíciles de ampliar. Una aplicación difícil de ampliar puede funcionar aceptablemente con cuatro usuarios, pero no es probable que lo haga con cientos. Las aplicaciones Web ASP.NET, en particular, deben ser fácilmente escalables, porque el tráfico de un sitio Web puede crecer en órdenes de magnitud en un periodo de tiempo muy corto.
• En las aplicaciones Web ASP.NET, los componentes están desconectados entre sí inherentemente. El explorador solicita una página al servidor; cuando el servidor termina de procesar y enviar la página, no tiene ninguna conexión con el explorador hasta la próxima petición. Bajo estas circunstancias, el mantenimiento de conexiones abiertas con una base de datos no es viable, porque no hay modo de saber si el consumidor de datos (el cliente) continúa necesitando acceso a los datos.
• Un modelo basado en datos continuamente conectados puede hacer difícil y poco práctico el intercambio de datos entre los límites de las aplicaciones y la organización por medio de una arquitectura conectada. Si dos componentes necesitan compartir los mismos datos, es necesario que estén conectados o idear un medio para que los componentes intercambien datos.

Por todas estas razones, el acceso a datos con ADO.NET se diseñó en torno a una arquitectura que utiliza conexiones con moderación. Las aplicaciones se conectan a la base de datos sólo durante el tiempo necesario para extraer o actualizar los datos. La base de datos ya no contiene conexiones que la mayor parte del tiempo permanecen inactivas, así que puede dar servicio a muchos más usuarios.

Las interacciones con la base de datos se realizan mediante comandos de datos

Para efectuar operaciones en una base de datos, se ejecutan instrucciones SQL o procedimientos almacenados (que incluyen instrucciones SQL). Las instrucciones SQL o los procedimientos almacenados se usan para leer y escribir en filas y para ejecutar funciones agregadas, como la adición o la obtención de un promedio. Asimismo, se utilizan para crear o modificar tablas o columnas, realizar transacciones, etc.

En ADO.NET los comandos de datos se usan para empaquetar las instrucciones SQL o los procedimientos almacenados. Por ejemplo, si se desea leer un conjunto de filas de una base de datos, se crea un comando de datos y se configura con el texto de una instrucción SQL Select o con el nombre del procedimiento almacenado que recupera registros.

Cuando se desea obtener las filas, se hace lo siguiente:

1. Abrir una conexión.
2. Invocar a un método Execute del comando, que a cambio:

   1. Ejecuta la instrucción SQL o el procedimiento almacenado al que hace referencia el comando.

   2. A continuación, cierra la conexión.

      La conexión permanece abierta sólo el tiempo necesario para ejecutar la instrucción o el procedimiento almacenado.

Cuando se invoca al método Execute de un comando, éste devuelve un valor. Los comandos que actualizan la base de datos devuelven el número de filas afectadas; otros tipos de comandos devuelven un código de error. Si el comando consulta la base de datos mediante una instrucción SELECT, puede devolver un conjunto de filas, recuperables mediante un lector de datos que actúa como un cursor de sólo lectura y sólo avance muy rápido. Para obtener más información, vea Recuperar datos mediante DataReader.

Nota de seguridad   Cuando utilice comandos de datos con una propiedad CommandType definida como Text, compruebe con cuidado la información que se envía desde el cliente antes de pasarla a la base de datos. Usuarios con malas intenciones podrían intentar enviar (inyectar) instrucciones de SQL modificadas o adicionales con el fin de obtener acceso no autorizado o dañar la base de datos. Antes de transferir la entrada del usuario a una base de datos, debe comprobar siempre que la información es válida; un procedimiento recomendado es utilizar siempre que sea posible consultas parametrizadas o procedimientos almacenados. Para obtener más información, vea Ataques mediante secuencias de comandos.

Si es necesaria más de una operación, por ejemplo, leer algunas filas y, a continuación, actualizarlas, se usan varios comandos de datos, uno por cada operación, ya que cada operación se ejecuta de forma independiente. Por ejemplo, para leer las filas, se abre la conexión, se leen las filas y, a continuación, se cierra la conexión. Cuando se desea actualizar datos, se abre la conexión de nuevo, se realiza la actualización y, a continuación, se cierra la conexión otra vez.

Los comandos de datos pueden incluir parámetros (específicamente, una colección de objetos de parámetro) que permiten crear consultas parametrizadas como las siguientes:

Select * From customers Where (customer_id = @customerid)

Posteriormente, se pueden establecer los parámetros en tiempo de ejecución y ejecutar el comando para que devuelva o actualice los datos deseados.

Los datos se pueden almacenar en memoria caché en conjuntos de datos

La tarea más común relacionada con datos consiste en recuperar datos de la base de datos y hacer algo con ellos: mostrarlos, procesarlos o enviarlos a otro componente. Con mucha frecuencia, la aplicación necesita procesar no sólo un registro, sino un conjunto de ellos: una lista de clientes o los pedidos del día, por ejemplo. A menudo, el conjunto de registros que necesita la aplicación procede de más de una tabla: mis clientes y todos sus pedidos; todos los autores que se llamen "Smith" y los libros que escribieron; y otros conjuntos similares de registros relacionados.

Una vez extraídos estos registros, la aplicación suele trabajar con ellos como grupo. Por ejemplo, es posible que la aplicación permita al usuario recorrer todos los autores que se llamen "Smith" y examinar los libros de uno de ellos, moverse a continuación al siguiente Smith y así sucesivamente.

En la mayoría de los casos, no resulta práctico volver a la base de datos cada vez que la aplicación necesite procesar el siguiente registro, ya que hacer esto puede anular la mayor parte de las ventajas que conlleva minimizar la necesidad de conexiones abiertas. Una solución, por lo tanto, es almacenar temporalmente los archivos recuperados de la base de datos y trabajar con este conjunto temporal.

En esto consiste un conjunto de datos. Un conjunto de datos es una memoria caché de registros recuperados de un origen de datos. Funciona como un almacén virtual de datos: un conjunto de datos incluye una o más tablas basadas en las tablas de la base de datos real y puede incluir información acerca de las relaciones entre estas tablas y las restricciones para los datos que puede contener cada tabla.

Los datos del conjunto de datos suelen ser una versión muy reducida de lo que hay en la base de datos. Sin embargo, puede trabajar con ellos igual que lo hace con los datos reales. Mientras esté trabajando, permanecerá desconectado de la base de datos, que quedará libre para ejecutar otras tareas.

Por supuesto, necesitará actualizar con frecuencia los datos de la base de datos (aunque no tan a menudo como recupera datos de ella). Puede ejecutar operaciones de actualización en el conjunto de datos, que se escribirán en la base de datos subyacente.

Una idea importante es que el conjunto de datos es un contenedor pasivo para los datos. Para extraer realmente datos de la base de datos y (opcionalmente) escribirlos de nuevo, se utilizan adaptadores de datos. Un adaptador de datos contiene uno o varios comandos utilizados para llenar una única tabla del conjunto de datos y para actualizar la tabla correspondiente de la base de datos. Normalmente, los adaptadores de datos contienen cuatro comandos: seleccionar, insertar, actualizar y eliminar filas de la base de datos. Por lo tanto, el método Fill de un adaptador de datos podría ejecutar una instrucción SQL tal como SELECT au_id, au_lname, au_fname FROM authors siempre que se llame al método.

Dado que un conjunto de datos es realmente una copia privada de los datos de la base de datos, no reflejará necesariamente el estado actual de la base de datos. Si desea ver los últimos cambios realizados por otros usuarios, puede actualizar el conjunto de datos; para ello, llame al método Fill correspondiente.

Una de las ventajas de utilizar conjuntos de datos es que los componentes pueden intercambiarlos cuando lo necesiten. Por ejemplo, un objeto comercial del nivel medio podría crear y llenar un conjunto de datos y, a continuación, enviarlo a otro componente en otro punto de la aplicación para que lo procese. Esta facilidad significa que los componentes no necesitan consultar la base de datos de forma individual.

Los conjuntos de datos son independientes de los orígenes de datos

Aunque un conjunto de datos actúa como una memoria caché para datos extraídos de una base de datos, el conjunto de datos no tienen ninguna relación real con la base de datos. El conjunto de datos es un contenedor; se llena con comandos SQL o procedimientos almacenados que se ejecutan desde un adaptador de datos.

Dado que un conjunto de datos no está sujeto directamente a un origen de datos, resulta un buen punto de integración para datos procedentes de múltiples orígenes. Por ejemplo, algunos datos de un conjunto de datos podrían proceder de su base de datos, mientras que otros podrían venir de una base de datos diferente o de un origen distinto a una base de datos como, por ejemplo, una hoja de cálculo. Parte de los datos de un conjunto de datos podrían llegar en una secuencia enviada por otro componente. Una vez que los datos se encuentren en un conjunto de datos, podrá trabajar con ellos mediante un modelo de objetos coherente, independientemente de cuál sea su origen.

Los datos se conservan como XML

Los datos deben moverse desde el almacén de datos hasta el conjunto de datos y de ahí a diversos componentes. En ADO.NET, el formato de transferencia de datos es XML. En consecuencia, si es necesario conservar datos (por ejemplo, en un archivo), se almacenarán como XML. Si tiene un archivo XML, puede utilizarlo como cualquier otro origen de datos y crear un conjunto de datos a partir de él.

En realidad, en ADO.NET, XML es un formato de datos fundamental. Las API de datos de ADO.NET crean automáticamente archivos XML o secuencias a partir de la información del conjunto de datos y los envían a otro componente. El segundo componente puede invocar API similares para leer el archivo XML y crear a partir de él un conjunto de datos. (Los datos no se almacenan en el conjunto de datos en formato XML — por ejemplo, no es posible analizar los datos de un conjunto de datos mediante un analizador de XML — sino en un formato más eficiente).

Los protocolos de datos basados en XML ofrecen muchas ventajas:

• XML es un formato estándar del sector. Esto significa que los componentes de datos de una aplicación podrán intercambiar datos con cualquier otro componente de cualquier otra aplicación, siempre que este componente entienda XML. Se están escribiendo muchas aplicaciones que entienden XML, lo que ofrece un nivel sin precedentes de intercambio entre aplicaciones diferentes.
• XML se basa en texto. La representación XML de los datos no utiliza información binaria, lo que permite enviarla mediante cualquier protocolo, como por ejemplo HTTP. La mayor parte de los servidores de seguridad bloquean la información binaria; sin embargo, si el formato de la información es XML, los componentes pueden continuar intercambiando fácilmente la información.

Para la mayoría de los escenarios, no es necesario saber XML para utilizar datos en ADO.NET, ya que convierte automáticamente los datos a XML y viceversa según sea preciso; usted interactúa con los datos utilizando métodos de programación ordinarios.

Las estructuras de datos están definidas por esquemas

Aunque para leer y escribir en la base de datos, y trabajar con conjuntos de datos, no es necesario saber nada sobre XML, hay situaciones en las que el objetivo que se persigue consiste precisamente en trabajar con XML. En estas situaciones no se tiene acceso a los datos, sino que se trabaja con su diseño. Para decirlo de otra manera, en ADO.NET se utiliza XML directamente cuando se trabaja con metadatos.

Los conjuntos de datos se representan como XML. La estructura del conjunto de datos, es decir, la definición de las tablas, columnas, tipos de datos, restricciones, etc. que se encuentran en el conjunto de datos, se define por medio de un esquema XML basado en el lenguaje de definición de esquemas XML (XSD). Al igual que los datos que contiene un conjunto de datos pueden cargarse y serializarse como XML, la estructura del conjunto de datos puede cargarse y serializarse como un esquema XML.

En la mayor parte del trabajo que realice con datos en ADO.NET, no tendrá que profundizar mucho en los esquemas. Habitualmente, las herramientas de Visual Studio .NET generan y actualizan los esquemas según sea necesario, sobre la base de lo que se hace en los diseñadores visuales. Por ejemplo, cuando utilice las herramientas para crear un conjunto de datos que represente tablas de la base de datos, Visual Studio .NET generará un esquema XML que describa la estructura del conjunto de datos. A continuación, se utilizará el esquema XML para generar un conjunto de datos con tipo, en el que los elementos de datos (tablas, columna, etc.) estarán disponibles como miembros de primera clase. Para obtener más información acerca de los conjuntos de datos con tipo, vea Introducción a conjuntos de datos.

Sin embargo, hay ocasiones en las que deseará crear o editar esquemas personalmente. Un ejemplo típico es el desarrollo de un esquema en colaboración con un socio o cliente. En este caso, el esquema sirve como contrato entre usted y el socio en lo relativo a la forma de los datos basados en XML que se van a intercambiar. En esta situación, a menudo tendrá que asignar los elementos del esquema a la estructura de su propia base de datos. Para obtener más información sobre el diseño de esquemas, vea Datos y esquemas XML.

Componentes de ADO.NET

La siguiente ilustración muestra los componentes principales de una aplicación ADO.NET.

Componentes de datos ADO.NET

La siguiente tabla resume los componentes ADO.NET que se ilustran anteriormente y proporciona vínculos para ampliar la información.

Vea también

Ventajas de ADO.NET | Comparación de ADO.NET con ADO | Conjuntos de datos ADO.NET | Adaptadores de datos ADO.NET | Acceso a datos con ADO.NET | XML en Visual Studio | Datos y esquemas XML