Hola.
Tal como les prometí, aqui estoy de nuevo..
Lamentablemente, para los lectores sin tiempo, debo hacer una pequeña reseña de ADO .NET2.0.
Para conocer el presente, es imperativo que sepamos de donde venimos… es por ello que inicio con una breve introducción a ADO .Net 1.0
ADO .Net 1.0
Con el lanzamiento del Framework 1.0, Microsoft presenta un nutevo modelo de acceso a datos: ADO .NET. ADO .Net es la evolución del modelo anterior mejor conocido como ADO (ActiveX Data Object), aunque ADO .Net no es Activex, se mantuvo el nombre ADO para «mostrar que es la nueva versión de ADO».
ADO .Net 1.0 soportaba comunicación con origenes de datos vía ODBC u OLEDB, pero también proporcionaba la opción de trabajar con proveedores de datos especificos para ciertos origenes de datos, llamados Proveedores Administrados. Estos proveedores administrados ofrecian (y ofrecen) un mejor performance ya que «hablaban directamente con el origen de datos».
ADO.Net nos presentó un modelo de objetos completamente nuevo:
- Connection: objeto responsable por establecer (y mantener) la comunicación con el origen de datos
- Command: este objeto almacena las consultas (query) que van a ser ejecutadas contra el origen de datos
- DataReader: proporciona un acceso rápido, hacia adelante y de solo lectura (parecido al recorset no?)
- DataSet:proporciona un mecanismo de almacenamiento para datos desconectados. Es capaz de mantener en «su interior» datos que provienen de múltiples origenes de datos. Para entenderlo rápidamente, les recomiendo que piensen en el como un repositorio en memoria para almacenar los datos que provienen de cualquier base de datos…
- DataAdapter: establece un puente entre el dataset y el origen de datos, en otras palabras es el responsable de obtener los datos del objeto Command y llenar el dataset con los mismos. Tambien se encarga de manejar el tema de la persistencia de los cambios realizados en el dataset (envío de cambios a la base de datos)
Otro tema importante que introdujo ADO .Net 1.0, fue el manejo de pool de conexiones (connection pooling), con esta caracteristicas se acabo con el costo excesivo que traía consigo el mantenimiento de una conexión abierta o la creación y destrucción de la misma. Con ADO .Net cuando una conexión es destruida en el código el Framework la mantiene viva (o abierta¿?) en un «pool», de manera que la próxima vez que se necesite establecer nuevamente una conexión (con las mismas credenciales) , la conexión es tomada del pool, sin que se necesite crear una nueva.
Si deseas conocer más acerca de las muchas nuevas características de ADO .Net, te recomiendo que revises la documentación en MSDN
ADO .NET 2.0
El lanzamiento del Framework 2.0, trajo consigo una nueva versión de ADO .Net. Pero tranquilos. La transición es sencilla, casi que sin impacto :-p.
En primer lugar ADO .Net 2.0, es 100% compatible con el código escrito para ADO .Net 1.0 :-D. En ADO .Net 2.0 el diseño básico del modelo de objetos es el mismo. Sólo se agregaron varias características nuevas para hacer las tareas comunes, más fáciles de realizar.
Una de las cosas nuevas que trajo ADO .Net 2.0 fue un mejor diseño y funcionamiento del pool de conexiones y el manejo de la serialización XML.
Otro ejemplo es la capacidad de obtener notificaciones cuando los datos cambian, esto elimina la necesidad de de periodicamente recargar los datos para asegurarnos de que los datos del usuario estan actualizados. También se incorporó la capacidad de ejecutar múltiples queries al mismo tiempo y recibir una serie de resultados (MARS=MULTIPLE ACTIVE RESULTS). Eliminando «la ida y vuelta», a nivel de la comunicación , que es necesaria para ejecutar un query y esperar por su resultado aumenta el performance de una aplicación que necesita ejecutar múltiples queries una trás otra; así p. ej. si el usuario quiere hacer otra tarea mientras se espera por los datos, es posible disparar un comando en modo asincrono. Esto también ha sido simplificado con ADO .Net 2.0.
Se ha incluido también una nueva API de «descubrimiento de bases de datos» para examinar el esquema de una base de datos. También tenemos la opción de escribir código de acceso a datos independiente del proveedor de datos, así tenemos la posibilidad de ofrecer aplicaciones que se pueden conectar a cualquier origen de datos…
Claro, esto es solo una muestra de las cosas que podemos hacer. Muchas de ellas son temas avanzados que no vamos a tocar en esta serie; así que manos al MSDN si desean mayor información sobre ADO .Net 2.0.
Bueno, hasta aqui esta bueno de teoría. En el próximo post les prometo que veremos algo de código 🙂
Cambio y fuera
Oscar
Post cruzado desde msmvps.com/blogs/oberroteran
.png "Visual Studio 2008")
