Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
A medida que la programación de aplicaciones ha evolucionado, las nuevas aplicaciones se han convertido en aplicaciones de correspondencia imprecisa basadas en el modelo de aplicación Web. Las aplicaciones de hoy en día utilizan cada vez más XML para codificar datos que se van a pasar a través de conexiones de red. Las aplicaciones Web usan HTTP para las comunicaciones entre niveles y, por tanto, deben controlar expresamente el mantenimiento del estado de una solicitud a otra. Este nuevo modelo es muy diferente del estilo de programación con conexión y de correspondencia precisa que caracterizaba la época cliente-servidor, en la que una conexión permanecía abierta durante toda la vida del programa y no hacía falta controlar el estado.
A la hora de diseñar herramientas y tecnologías para satisfacer las necesidades del programador de hoy en día, Microsoft se dio cuenta de que hacía falta un modelo de programación totalmente nuevo para el acceso a datos, un modelo basado en .NET Framework. Tomar .NET Framework como base garantizaba que la tecnología de acceso a datos sería uniforme: los componentes compartirían un sistema de tipos, unos modelos de diseño y unas convenciones de nomenclatura.
ADO.NET se diseñó con el propósito de satisfacer las necesidades de este nuevo modelo de programación: arquitectura de datos sin mantener una conexión abierta, estrecha integración con XML, representación común de datos con la posibilidad de combinar datos procedentes de múltiples y variados orígenes, y servicios optimizados para interactuar con una base de datos, todo ello nativo de .NET Framework.
A la hora de crear ADO.NET, Microsoft se propuso los siguientes objetivos de diseño.
Aprovechar los conocimientos actuales de ADO
El diseño de ADO.NET satisface muchos de los requisitos del modelo de desarrollo de aplicaciones de hoy en día. Al mismo tiempo, el modelo de programación sigue siendo lo más parecido posible a ADO, de manera que los programadores actuales de ADO no tienen que empezar a aprender desde cero una tecnología de acceso a datos totalmente nueva. ADO.NET forma parte intrínseca de .NET Framework sin que al programador de ADO le parezca completamente extraña.
ADO.NET coexiste con ADO. Aunque la mayoría de las nuevas aplicaciones basadas en .NET se escribirán mediante ADO.NET, ADO sigue estando disponible para el programador de .NET a través de los servicios de interoperabilidad COM de .NET.
Para obtener una descripción de las diferencias entre ADO y ADO.NET, vea "ADO.NET para el programador de ADO" en https://msdn.microsoft.com/library/en-us/dndotnet/html/ADONETProg.asp.
Admitir el modelo de programación N-Tier
ADO.NET proporciona compatibilidad de primera clase con el entorno de programación n-tier sin mantener una conexión abierta para el que están escritas muchas aplicaciones nuevas. La idea de trabajar con un conjunto de datos sin mantener una conexión abierta se ha convertido en un objetivo del modelo de programación. La solución de ADO.NET para la programación n-tier es el DataSet.
Integrar la compatibilidad con XML
XML y el acceso a datos están estrechamente relacionados: XML consiste en codificar datos y el acceso a datos consiste cada vez más en XML. .NET Framework no sólo admite los estándares Web, sino que está basado totalmente en ellos.
La compatibilidad con XML está integrada en los cimientos de ADO.NET. Las clases de XML incluidas en .NET Framework y ADO.NET forman parte de la misma arquitectura: están integradas en muchos niveles. Ya no es necesario elegir entre el conjunto de servicios de acceso a datos y los correspondientes servicios de XML; la capacidad para cruzar de uno a otro es inherente al diseño de ambos.
Vea también
Información general acerca de ADO.NET | Acceso a datos con ADO.NET | DataSet (Clase)