ADO .NET para Programadores de ADO

Artículo
10/14/2008

Por Geykel Raúl Moreno Ceballos

Contenido

Introducción
Visión general
Diseño de ADO
ADO .NET
Tipos de datos
Elegir un DataReader o un DataSet
Conclusión

Introducción

En el .NET Framework, Microsoft introduce ADO .NET, una evolución de la arquitectura de acceso a datos proveída por el modelo de programación Microsoft ActiveX Data Objects (ADO). ADO .NET no viene a reemplazar a ADO para los programadores de COM; más bien, éste provee a los programadores de .NET un acceso a las fuentes de datos relacionales, XML y aplicaciones de datos. ADO .NET ayuda a una variedad de necesidades de desarrollo, incluyendo clientes de bases de datos y objetos del negocio intermedios usados por aplicaciones, herramientas, lenguajes y navegadores de Internet. Este artículo presenta una visión general de la arquitectura de acceso a datos disponible a través de ADO .NET.

Visión general

Desde su nacimiento, ADO ha proveído una eficiente y robusta interfaz para el trabajo con datos a los programadores de COM. ADO es extensamente usado por diferentes variedades de almacenes porque éste puede ser llamado desde cualquier lenguaje incluyendo Microsoft Visual Basic 6.0, Microsoft Visual C++, y una gran variedad de interfaces de scripting.

ADO .NET es una evolución de ADO que provee una mejor interoperabilidad de plataformas y acceso a datos escalable. Creando un nuevo conjunto de API de acceso a datos en ADO .NET nos ofrece las siguientes ventajas sobre portar directamente ADO al .NET Framework:

Mejor integración con XML: Subsiguiente al diseño de ADO, XML comenzó a jugar un papel cada vez más significante en el diseño de aplicaciones. ADO .NET aprovecha la eficacia de XML para proporcionar acceso a datos sin mantener una conexión abierta. ADO .NET fue diseñado teniendo en cuenta las clases de XML incluidas en .NET Framework: ambos son componentes de una única arquitectura. ADO .NET y las clases de XML incluidas en .NET Framework convergen en el objeto DataSet. El DataSet se puede llenar con datos procedentes de un origen XML, ya sea éste un archivo o una secuencia XML. El DataSet se puede escribir como XML compatible con el del consorcio World Wide Web (W3C), incluyendo su esquema como esquema XSD (Lenguaje de definición de esquemas XML), independientemente del origen de los datos incluidos en el DataSet. Puesto que el formato nativo de serialización del DataSet es XML, es un medio excelente para mover datos de un nivel a otro, por lo que el DataSet es idóneo para utilizar datos y contextos de esquemas de interacción remota desde y hacia un servicio Web XML. ADO .NET además usa herramientas XML para llevar a cabo validaciones, consultas jerárquicas y transformaciones de datos en datos relacionales.
Integración con el .NET Framework : Las construcciones de ADO, como los Recordset, no emplean construcciones de programación familiares pero en cambio son modelados para ser orientados a la base de datos. Por ejemplo, los cursores que se usan para navegar y recuperar datos funcionan diferente a otras construcciones de datos tales como los arreglos y las colecciones. Sin embargo, en ADO .NET los datos pueden ser expuestos en memoria a través de estructuras comunes del .NET Framework, incluyendo arreglos y colecciones, proveyéndote de métodos de acceso comunes cuando trabajas con datos relacionales.
Mejor soporte para el modelo de negocio desconectado: ADO provee limitado soporte para el acceso desconectado usando Recordset. ADO .NET introduce un nuevo objeto, el DataSet , esencial para admitir escenarios de datos distribuidos de ADO .NET sin mantener una conexión. El DataSet es una representación residente en memoria de datos que proporciona un modelo de programación relacional coherente independientemente del origen de datos. Se puede utilizar con múltiples y distintos orígenes de datos, con datos XML o para administrar datos locales de la aplicación. El DataSet representa un conjunto completo de datos entre los que se incluyen tablas relacionadas, restricciones y relaciones entre las tablas. En la Figura 1 se muestra el modelo de objeto DataSet.

Figura 1: Modelo de objeto DataSet. Volver al texto.
Los métodos y objetos contenidos en un DataSet son coherentes con los del modelo de base de datos relacional. El DataSet también puede persistir y volver a cargar su contenido como XML y su esquema como esquema XSD (Lenguaje de definición de esquemas XML).
Control explícito de los comportamientos de acceso a dato: El diseño de ADO incorpora comportamientos implícitos que podrían no siempre ser los requeridos por la aplicación y esto podría por consiguiente limitar el rendimiento. ADO .NET provee componentes factorizados bien definidos con comportamientos y rendimiento predecibles y una semántica que te permite dirigir escenarios comunes de una manera favorablemente perfeccionada.
Mejor soporte en tiempo de diseño: ADO deriva información acerca de los datos implícitamente en tiempo de ejecución, basado en la metadata que frecuentemente es costosa de obtener. ADO .NET, por otra parte, obtiene la metadata conocida en tiempo de diseño con el propósito de proveer un mejor rendimiento y comportamiento consistente en tiempo de ejecución.

Diseño de ADO

Para entender mejor el modelo y diseño de ADO .NET, es útil repasar algunos de los principales aspectos de ADO. ADO usa un objeto sencillo, el Recordset, como representación común para trabajar con todos los tipos de datos. El Recordset se utiliza para trabajar solamente con un flujo hacia delante ( forward-only ) de resultados de la base de datos, para desplazarse a través de los datos guardados en un servidor, o para desplazarse a través de un conjunto de resultados cacheados. Los cambios hechos a los datos pueden ser aplicados inmediatamente en la base de datos, o aplicados en lote usando búsquedas óptimas y operaciones de actualización. Puedes especificar la funcionalidad deseada cuando creas el Recordset, y el comportamiento del Recordset resultante puede variar enormemente dependiendo de las propiedades que desees. Debido a que ADO utiliza un objeto sencillo que puede comportarse de muchas formas diferentes, te permite mantener el modelo de objetos de tu aplicación muy simple. Sin embargo, es difícil escribir código común, previsible y optimizado porque el comportamiento, rendimiento y la semántica exhibida por este objeto varía grandemente dependiendo de cómo el objeto es generado y a qué dato está accediendo. Esta es una realidad particular para componentes genéricos (como el control grilla “ grid control ”) que intenta consumir datos que no han sido generado por el componente y por lo cual el componente no tiene la habilidad de especificar el comportamiento o funcionalidad requerida.

ADO .NET

En el diseño de ADO .NET, se tuvieron en consideración tareas a las cuales se enfrenta un desarrollador comúnmente cuando accede o trabaja con datos. Al contrario de usar un objeto simple para llevar a cabo un determinado número de tareas, ADO .NET agencia funcionalidades específicas en objetos explícitos que están optimizados para permitir al desarrollador llevar a cabo de cada una de las tareas. La funcionalidad que un Recorset de ADO provee ha sido dividida en los siguientes objetos explícitos en ADO .NET: el DataReader , que provee un acceso rápido, hacia delante ( forward-only ) y de sólo lectura en los resultados de una consulta; el DataSet , que provee una representación relacional de los datos en memoria; y el DataAdapter , que provee un puente entre el DataSet y la fuente de datos. El objeto Command de ADO .NET incluye además funcionalidad explícita tales como el método ExecuteNonQuery para comandos que no retornan filas, y el método ExecuteScalar para consultas que devuelven un único valor en cambio de un conjunto de filas. Para una mejor comprensión de cómo el diseño de ADO .NET está constituido por objetos optimizados para llevar a cabo un comportamiento explícito, considera las siguientes tareas comunes cuando se trabaja con datos:

Flujos de datos hacia delante y de sólo lectura: Frecuentemente las aplicaciones procesan una seria de resultados en tiempo de ejecución, sin requerir la interacción del usuario y no tener que actualizar o desplazarse hacia atrás a través de los resultados mientras se van leyendo. En ADO este tipo de recuperación de datos se lleva a cado utilizando el Recordset. En ADO .NET, sin embargo, el objeto DataReader optimiza este tipo de recuperación de datos proveyendo un flujo sin el uso de buffers, hacia delante ( forward-only ), y de sólo lectura proveyendo un mecanismo más eficiente de recuperación de resultados de una base de datos. La mayor parte de esta eficiencia se obtiene como resultado de que el DataReader fue diseñado con este propósito solamente, sin tener que enfrentarse a escenarios donde los datos son actualizados hacia la fuente de datos o cacheado localmente como con los Recordset de ADO.
Acceso desconectado a datos: Un caso frecuente para exponer datos es en una representación en la cual el usuario pueda navegar en ellos sin atarse a restricciones o ligarse a recursos en el servidor. Algunos ejemplos de este escenario es cuando vinculamos datos a un control o combinamos datos de diferentes fuentes de datos y/o XML. El Recordset de ADO provee algún soporte para estos escenarios, usando un cursor del lado del cliente. Sin embargo, en ADO .NET el DataSet está diseñado para estas tareas. El DataSet provee una representación común y completamente desconectada de los datos que puede guardar resultados de distintas fuentes de datos. Debido a que el DataSet es completamente independiente de la fuente de datos, provee el mismo rendimiento y semántica sin tener en cuenta desde dónde se están cargando los datos, desde una base de datos, desde un fichero XML, o si son generados por la aplicación. Un simple DataSet puede contener tablas copuladas desde distintas bases de datos u otras fuentes que no necesariamente tienen que ser bases de datos; toda la apariencia y comportamiento para el cliente del DataSet será exactamente el mismo. Las capacidades relacionales del DataSet proveen un avance sobre el Recordset las cuales son limitadas exponiendo datos de diferentes tablas, o para retornar múltiples conjuntos de datos distintos, teniendo el desarrollador que manipular y relacionar los datos manualmente, el* * DataSet provee mucha más flexibilidad cuando trabaja con conjuntos de datos relacionados, además provee la habilidad de transmitir resultados desde un cliente remoto o servidor en formato XML, usando el lenguaje de definición de esquema de XML (XSD Schema definition language).
Recuperando y actualizando datos desde la fuente de datos: El DataAdapter de ADO .NET provee un puente entre el DataSet y la fuente de datos. El DataAdapter se usa para llenar un DataSet con resultados obtenidos desde la base de datos, y para leer cambios en el DataSet * *y actualizarlos a la base de datos. Usando un objeto separado, el DataAdapter , para comunicarse con la base de datos permite completamente al DataSet mantenerse genérico con respecto a los datos que contiene, y permite que tengas un mayor control sobre cuándo y cómo se ejecutan los comandos y se envían los cambios a la base de datos. ADO desempeña mucho de este comportamiento implícitamente, sin embargo, el diseño explícito de ADO .NET nos permite una mejor interacción con la fuente de datos para un mejor rendimiento y escalabilidad.

Tipos de datos

En ADO, todos los resultados se retornan en el tipo estándar OLE Automation Variant . Esto puede deteriorar el rendimiento porque, además de los gastos en las conversiones, a Variant se le asigna espacio en memoria usando task-allocated system memory , lo cual provoca contenciones a través del sistema. Cuando recuperamos resultados desde un DataReader en ADO .NET, sin embargo, puedes obtener columnas en su tipo de dato nativo, como un objeto común de la clase Object , sin tener que pasar por conversiones costosas. Los valores de los datos pueden exponerse tanto como tipos del .NET Framework, o pueden ponerse en una estructura propia en el .NET Framework para preservar la fidelidad del tipo de dato nativo. Un ejemplo de esto es el SQL Server .NET Data Provider, el cual puede ser usado para exponer datos provenientes de Microsoft SQL Server como tipo de datos del .NET Framework, o como tipo propio definido en las clases del espacio de nombres System.Data.SqlTypes .

Elegir un DataReader o un DataSet

A la hora de decidir si tu aplicación debe utilizar un DataReader o un DataSet, debes tener en cuenta el tipo de funcionalidad que tu aplicación requiere. Usa un DataSet para hacer lo siguiente: utilizar datos de forma remota entre un nivel y otro o desde un servicio Web XML; Interactuar con datos dinámicamente, por ejemplo, para enlazar con un control de Windows Forms o para combinar y relacionar datos procedentes de varios orígenes; Almacenar datos en memoria caché localmente, dentro de tu aplicación; Proporcionar una vista XML jerárquica de datos relacionales y utilizar herramientas como una transformación XSL o una consulta Xpath (XML Path Language) en tus datos. Realizar procesamientos exhaustivos de datos sin necesidad de tener una conexión abierta con el origen de datos, lo que libera la conexión para que la utilicen otros clientes. Si no necesita la funcionalidad proporcionada por el DataSet, puede mejorar el rendimiento de tu aplicación si utilizas el DataReader para devolver tus datos de sólo avance y de sólo lectura. Aunque el DataAdapter usa el DataReader para rellenar el contenido de un DataSet, al utilizar el DataReader puedes mejorar el rendimiento porque no usarás la memoria que utilizaría el DataSet, además de evitar el procesamiento necesario para crear y rellenar el contenido del DataSet.

Conclusión

ADO .NET está diseñado para fundamentarse en la fuerza del modelo de programación de ADO, mientras que provee una evolución en la tecnología de acceso a datos para responder a las necesidades cambiantes del desarrollador. Está diseñado para fortalecer tus conocimientos de ADO, mientras que provee un control más fino sobre los componentes, recursos y comportamiento de tu aplicación cuando accede y trabaja con datos.

Geykel Raúl Moreno Ceballos es estudiante del 4º año de la Ingeniería en Informática. Trabaja como Desarrollador Web utilizando ASP .net y C#. Posee experiencia con ASP, ADSI, Microsoft SQL Server, Visual Basic Script y Delphi, entre otras. Actualmente trabaja en un grupo de Inteligencia Artificial. Ha obtenido la 2a. Estrella del programa Desarrollador Cinco Estrellas de Microsoft MSDN.