---

***Microsoft SQL Server 2000 Enterprise version***



Almost every software application is driven by data access and data management-based code. This is most prevalent in business process-focused applications in which data-rich objects are the core of applications. An integral part of these data driven applications are the APIs used for data access and data manipulation. These APIs are what ultimately drive the features produced by the developer, the maintainability of the application, and the extensibility of the application.

The evolution of data access API has been a painfully iterative process focusing predominantly on how to deal with relational data in a more flexible manner. We have seen the rise and fall of ODBC, Microsoft® Jet, Data Access Objects (DAO) and Remote Data Objects (RDO), in addition to many non-Microsoft-based APIs. These APIs did not bridge the gap between object-based and semi-structured (XML) data programming needs, on the one hand, and the rigid world of normalized relational data, on the other. Combine this problem with the task of dealing with heterogeneous data stores, non-relational data like XML and applications operating across multiple languages and you have a tremendous opportunity for complete re-architecture.

Embracing similar challenges in the data access space, Microsoft has spent a great deal of time and effort redesigning the basic APIs that are used to build applications. The main deliverable from this process is the Microsoft .NET Framework. One of the primary design goals for the .NET Framework was to provide developers a more simplified and extensible development platform for distributed application development. In addition, the .NET Framework should be able to be used to build any type of application from the simplest console application to a completely distributed XML Web service driven application.

What is ADO.NET? From an architect's perspective ADO.NET represents the abstract design concepts used to build the data access classes within the .NET Framework. These classes will be reviewed later, but it is first important to understand why these classes were created and how they evolved from current data access APIs. There were several main design goals driving ADO.NET:

* Explicit and factored object model. ADO.NET is designed to be a simple to use object model in which the developer has complete control over how to control data source connectivity, command execution, and data manipulation.
* Disconnected data cache model. N-tier programming and XML Web service architecture require that applications can participate in a disconnected, loosely coupled manner. ADO.NET provides a comprehensive caching data model for marshalling data between applications or services and then to optimistically update the original data sources or source.
* XML support. XML is the key to building interoperable applications and more robust data processing models. XML support has been built directly into the .NET Framework. ADO.NET leverages this implementation by providing a seamless interaction with XML in a relational manner or in a native XML manner.
* Leverage existing ADO knowledge. Although the ADO.NET object model is different from the existing ADO model, the basic constructs are the same. The ADO.NET object model consists of a provider, connection, and command objects. Thus current ADO developers should be able to efficiently migrate to ADO.NET.

From a developer's perspective ADO.NET represents the concrete implementation of classes inside the .NET Framework used for data access. The following section reviews the overall physical architecture and hierarchy of the classes.

Architecture

The ADO.NET architecture can be divided into two logical pieces: command execution and caching. Command execution requires features like connectivity, execution, and reading of results. These features are enabled with .NET data providers. Caching of results is handled by the DataSet.

The provider enables connectivity and command execution to underlying data sources. Note that these data sources do not have to be relational databases. Once a command has been executed the results can be read using a DataReader. A DataReader provides efficient forward-only stream level access to the results. In addition, results can be used to render a DataSet a DataAdapter. This is typically called "filling the DataSet."

The DataSet object represents a disconnected cache of data. This cache is made up of DataTables and DataRelations that represent the results of the command. The DataSet tracks changes to the underlying data in the cache. Changes can be submitted back to the original data source by using the DataAdapter and applicable Insert, Update, or Delete commands. The DataSet also provides a direct XML view of the underlying data in the cache. This XML can be manipulated with XML standards like XPath and XSLT.

Click this bar to view the full image.

In addition to being filled through a .NET data provider, the DataSet can also be filled with raw XML data simply by loading it from a file or XML Document. Further details about the XML integration within ADO.NET appear later in this document.

The .NET provider objects are provider-specific. The above objects (Connection, Command, DataAdapter, DataReader) are abstract representations that each provider developer could implement. Thus there will be separate Connection, Command, DataReader, and DataAdapter implementations for each data source. This is much different from the existing ADO model in which OLE DB providers integrate into the common ADO connection, Command, and Recordset objects. This approach was taken in order to let the .NET data provider implementer take full advantage of the underlying features of the data source. This removes several layers of abstraction inherent in the OLE DB provider model, and so improves performance and simplifies the object model.

Download