Ventajas de ADO.NET

Artículo
10/07/2008

Actualización: noviembre 2007

ADO.NET ofrece varias ventajas sobre las anteriores versiones de ADO y sobre otros componentes de acceso a datos. Estas ventajas se incluyen en las siguientes categorías:

Interoperabilidad

Las aplicaciones ADO.NET pueden aprovechar la flexibilidad y la amplia aceptación de XML. Dado que XML es el formato de transmisión de conjuntos de datos a través de la red, cualquier componente que pueda leer el formato XML podrá procesar los datos. En realidad, no es necesario en absoluto que el componente receptor sea un componente ADO.NET: el componente transmisor puede transmitir simplemente el conjunto de datos a su destino, independientemente de cómo esté implementado el componente receptor. El componente de destino podría ser una aplicación de Visual Studio o cualquier otra aplicación implementada con cualquier herramienta. El único requisito es que el componente receptor pueda leer XML. Como estándar del sector, XML se diseñó precisamente con el propósito de alcanzar este tipo de interoperabilidad.

Mantenibilidad

A lo largo de la vida de un sistema implementado es posible hacer cambios modestos, pero raramente se intenta hacer cambios importantes, estructurales, debido a su dificultad. Es de lamentar que sea así puesto que, en el curso natural de los acontecimientos, tales cambios importantes pueden hacerse necesarios. Por ejemplo, a medida que una aplicación implementada se hace más popular entre los usuarios, es posible que el aumento de la carga de rendimiento haga necesarios cambios estructurales. A medida que crece la carga de rendimiento en un servidor de la aplicación implementada, los recursos del sistema pueden escasear y el tiempo de respuesta y el rendimiento pueden resentirse. Ante este problema, los arquitectos de software pueden tomar la decisión de dividir en el servidor el procesamiento de la lógica de empresa y el procesamiento de la interfaz de usuario en niveles diferentes y en equipos separados. En la práctica, el nivel del servidor de aplicación se reemplaza con dos niveles, lo que alivia la escasez de recursos del sistema.

El problema no consiste en diseñar una aplicación de tres niveles. Por el contrario, se trata de aumentar el número de niveles después de implementar una aplicación. Si la aplicación original se implementó en ADO.NET mediante conjuntos de datos, esta transformación resulta más sencilla. Cuando reemplace un solo nivel por dos niveles, no olvide organizar estos dos niveles para que intercambien información. Dado que los niveles pueden transmitir datos por medio de conjuntos de datos con formato XML, la comunicación es relativamente fácil.

Programabilidad

En Visual Studio, los componentes de datos ADO.NET encapsulan funcionalidad de acceso a datos de diversas formas que ayudan a programar de modo más rápido y con menos errores. Por ejemplo, los comandos de datos condensan la tarea de generar y ejecutar instrucciones SQL o procedimientos almacenados.

De igual forma, las clases de datos ADO.NET generadas por las herramientas del diseñador tienen como resultado conjuntos de datos con tipo. Esto, a su vez, permite el acceso a los datos mediante programación con tipo. Por ejemplo, considere la siguiente línea de código, que obtiene acceso a un miembro de datos en un conjunto de datos sin tipo:

If totalCost > CType(dataSet1.Tables("Customers").Rows(n)("AvailableCredit"), Double) Then

if (totalCost > (double)dataSet1.Tables["Customers"].Rows[n]["AvailableCredit"])

La línea equivalente, con acceso a un miembro de datos de un conjunto de datos con tipo, tiene el aspecto siguiente:

If totalCost > dataSet2.Customers(n).AvailableCredit Then

if (totalCost > dataSet2.Customers[n].AvailableCredit)

El código correspondiente al conjunto de datos con tipo es más fácil de leer. También es más fácil de escribir, porque se proporciona la finalización de instrucciones. Por ejemplo, entre la lista de opciones para finalizar la siguiente instrucción se encuentra "AvailableCredit":

If totalCost > dataSet2.Customers(n).

Por último, el código correspondiente al conjunto de datos con tipo es más seguro, porque proporciona la comprobación de tipos en tiempo de compilación. Por ejemplo, suponga que AvailableCredit se expresa como un valor de moneda. Si el programador asigna, por error, un valor de cadena a AvailableCredit, el entorno le informaría del error en tiempo de compilación. Cuando se trabaja con conjuntos de datos sin tipo, el programador no sabe del error hasta el momento de la ejecución.

Para obtener más información sobre conjuntos de datos con y sin tipo, vea Información general sobre conjuntos de datos en Visual Studio.

Rendimiento

Para las aplicaciones desconectadas, los conjuntos de datos ADO.NET ofrecen ventajas de rendimiento frente a los conjuntos de registros ADO desconectados. Cuando se utiliza el cálculo de referencias de COM para transmitir un conjunto de registros desconectado entre niveles, la conversión de los valores del conjunto de registros a tipos de datos reconocibles por COM puede suponer un costo de procesamiento significativo. En ADO.NET, tal conversión de tipos de datos no es necesaria.

Escalabilidad

Dado que el Web puede incrementar en gran medida la demanda de datos, la escalabilidad adquiere una importancia crucial. Las aplicaciones para Internet tienen un suministro ilimitado de usuarios potenciales. Aunque una aplicación pueda dar un buen servicio a una docena de usuarios, eso no significa que pueda dar un servicio igualmente bueno a cientos o cientos de miles de ellos. Una aplicación que consuma recursos tales como bloqueos y conexiones de base de datos no dará un buen servicio a un gran número de usuarios, porque la demanda de recursos limitados por parte de los usuarios acabará por superar su disponibilidad.

Para facilitar la escalabilidad, ADO.NET anima a los programadores a ahorrar recursos limitados. Las aplicaciones ADO.NET utilizan un acceso desconectado a los datos, por lo que no retienen bloqueos ni conexiones activas con bases de datos durante largos períodos de tiempo.