Comparativa de ADO /ADO .NET

Comparativa de ADO /ADO .NET

Como punto de partida para comprender la importancia del nuevo diseño de ADO .NET, analizaremos los aspectos distintivos entre ADO .NET y el modelo ADO vigente hasta la fecha. Las diferencias existentes son muchas, y van desde el mismo diseño de los interfaces de las clases, hasta el nivel estructural de los componentes, pasando por el modo en cómo manejan la información. La Tabla 31 muestra estas diferencias.

El modelo de objetos de ADO .NET es mucho Clases de objetos mas estructuradas

más rico que el de ADO. Incorpora nuevas clases

de datos y encapsula mucha más potencia de uso a la par que corrige pequeños defectos de las versiones anteriores.

Independiente del lenguaje

Aprovechando la nueva arquitectura de servicios

de la plataforma .NET, ADO .NET puede ser usado como un servicio del sistema, pudiendo ser utilizado por cualquier aplicación escrita en cualquier lenguaje.

Representaciones en memoria de los datos

En ADO .NET se emplea el DataSet, mientras que en ADO se emplea el Recordset. No es sólo un cambio de nombre. En memoria y en rendimiento las cosas han cambiado mucho.

Número de tablas

Un Recordset de ADO sólo puede contener un único resultado (fruto de consultas complejas o no). En cambio, un DataSet puede representar un espacio de múltiples tablas simultáneamente. Esto permite obtener una representación de espejo de la base de datos a la que representa.

Navegación mejorada

En ADO sólo nos podemos mover secuencialmente fila a fila. En ADO .NET podremos navegar por filas en un DataSet, y consecuentemente avanzar en una fila/conjunto de filas de otro DataSet asociado a través de una colección de relaciones.

© Grupo EIDOS 36. Acceso a datos con ADO .NET

Acceso a datos Off-line (Desconectados)

En ADO .NET todos los accesos a datos se realizan en contextos desconectados de la base de datos. En ADO, es posible tener estructuras desconectadas, pero es una elección a tomar. Por defecto, ADO está pensado para contextos con conexión.

Además, ADO .NET realiza todos los accesos a los servicios de datos a través del objeto DataSetCommand, lo que permite personalizar cada comando en función del rendimiento y la necesidad del programa (en ADO, el Recordset puede modificar datos a través de su API de cursores, lo que muchas veces no es óptimo).

Compartimiento de datos entre capas, o bien, El traspaso de un recordset Off-line en ADO es

entre componentes

más complejo y pesado pues es necesario establecer un vínculo RPC y un proceso de COM marshalling (verificación de tipos de datos remotos). En ADO .NET para la comunicación entre componentes y capas se emplea un simple stream XML.

Tipos de datos más ricos

Debido al COM Marshalling los tipos de datos que se pueden usar vía RPC están muy limitados. En ADO .NET, gracias a los flujos XML, es posible enviar cualquier tipo de dato de manera sencilla.

Rendimiento

Tanto ADO como ADO .NET requieren de muchos recursos cuando se habla de envíos masivos de datos. El stress del sistema es proporcional al número de filas que se quieren procesar. Pero ADO .NET permite utilizar mucho más eficientemente los recursos, pues no tiene que realizar el COM Marshalling de datos, en lo que ADO sí (y eso supone un canal más de envío de datos de control que ADO .NET ahorra).

Por motivos de seguridad, las empresas suelen Penetración de firewalls

bloquear los sistemas de comunicaciones vía RPC. O bien, implementan pesados mecanismos

de control de acceso y envío de la información. Lo que complica los diseños, sus rendimientos y su instalación y distribución. En ADO .NET, puesto que no se realizan llamadas al sistema, sino que se envían flujos de datos en XML, se simplifica enormemente la configuración de estos dispositivos.

Tabla 31

Programación con Visual Basic .NET © Grupo EIDOS

De los anteriores puntos podemos obtener muy buenas conclusiones en cuanto a las mejoras introducidas en el nuevo modelo ADO .NET. Se puede resumir en un mejor mecanismo de comunicación entre procesos gracias a XML y una independencia del cliente con respecto al servidor, que posibilita el funcionamiento autónomo de la aplicación (mejor tolerancia a fallos, independencia del estado de la red).