Design Goals for ADO.NET
As application development has evolved, new applications have become loosely coupled, often based on the Web application model. More and more of today's applications use XML to encode data to be passed over network connections. Web applications use HTTP as the fabric for communication between tiers, and must explicitly handle maintaining state between requests. This new model is very different from the connected, tightly coupled style of programming that characterized the client/server era, where a connection was held open for the duration of the program's lifetime, and no special handling of state was required.
In designing tools and technologies to meet the needs of today's developer, Microsoft recognized that an entirely new programming model for data access was needed, and built it upon the .NET Framework. Building on the .NET Framework ensured that the data access technology would be uniform, because components would share a common type system, design patterns, and naming conventions.
ADO.NET was designed to meet the needs of this new programming model: disconnected data architecture, tight integration with XML, common data representation with the ability to combine data from multiple and varied data sources, and optimized facilities for interacting with a database, all native to the .NET Framework.
In creating ADO.NET, Microsoft embraced the following design goals:
Leverage current ActiveX Data Objects (ADO) knowledge.
Support the n-tier programming model.
Integrate XML support.
Leverage Current ADO Knowledge
The design for ADO.NET addresses many of the requirements of today's application development model. At the same time, the programming model stays as similar as possible to ADO, so current ADO developers do not have to start from the beginning. ADO.NET is an intrinsic part of the .NET Framework yet retains familiarity to the ADO programmer.
ADO.NET also coexists with ADO. Although most new .NET-based applications will be written using ADO.NET, ADO remains available to the .NET programmer through .NET COM interoperability services.
For a discussion of the differences between ADO and ADO.NET, see ADO.NET for the ADO Programmer.
Support the N-Tier Programming Model
The concept of working with a disconnected set of data has become a focal point in the programming model. ADO.NET provides first-class support for the disconnected, n-tier programming environment for which many new applications are written. The ADO.NET solution for n-tier programming is the DataSet.
For more information about DataSets, see Using DataSets in ADO.NET.
Integrate XML Support
XML and data access are closely tied. XML is about encoding data, and data access is increasingly becoming about XML. The .NET Framework does not just support Web standards; it is built entirely on top of them.
XML support is built into ADO.NET at a very fundamental level. The XML classes in the .NET Framework and ADO.NET are part of the same architecture; they integrate at many different levels. You therefore no longer have to choose between the data access set of services and their XML counterparts; the ability to cross over from one to the other is inherent in the design of both.
For more information about using XML with ADO.NET, see Using XML in a DataSet.