ADO.NET Architecture

Data processing has traditionally relied primarily on a connection-based, two-tier model. As data processing increasingly uses multi-tier architectures, programmers are switching to a disconnected approach to provide better scalability for their applications.

XML and ADO.NET

ADO.NET leverages the power of XML to provide disconnected access to data. ADO.NET was designed hand-in-hand with the XML classes in the .NET Framework — both are components of a single architecture.

ADO.NET and the XML classes in the .NET Framework converge in the DataSet object. The DataSet can be populated with data from an XML source, whether it is a file or an XML stream. The DataSet can be written as World Wide Web Consortium (W3C) compliant XML, including its schema as XML Schema definition language (XSD) schema, regardless of the source of the data in the DataSet. Because the native serialization format of the DataSet is XML, it is an excellent medium for moving data between tiers making the DataSet an optimal choice for remoting data and schema context to and from an XML Web service.

The DataSet can also be synchronized with an XmlDataDocument to provide relational and hierarchical access to data in real time. For more information, see Synchronizing a DataSet with an XmlDataDocument.

ADO.NET Components

The ADO.NET components have been designed to factor data access from data manipulation. There are two central components of ADO.NET that accomplish this: the DataSet, and the .NET Framework data provider, which is a set of components including the Connection, Command, DataReader, and DataAdapter objects.

The ADO.NET DataSet is the core component of the disconnected architecture of ADO.NET. The DataSet is explicitly designed for data access independent of any data source. As a result it can be used with multiple and differing data sources, used with XML data, or used to manage data local to the application. The DataSet contains a collection of one or more DataTable objects made up of rows and columns of data, as well as primary key, foreign key, constraint, and relation information about the data in the DataTable objects.

The other core element of the ADO.NET architecture is the .NET Framework data provider, whose components are explicitly designed for data manipulation and fast, forward-only, read-only access to data. The Connection object provides connectivity to a data source. The Command object enables access to database commands to return data, modify data, run stored procedures, and send or retrieve parameter information. The DataReader provides a high-performance stream of data from the data source. Finally, the DataAdapter provides the bridge between the DataSet object and the data source. The DataAdapter uses Command objects to execute SQL commands at the data source to both load the DataSet with data, and reconcile changes made to the data in the DataSet back to the data source.

You can write .NET Framework data providers for any data source. The .NET Framework ships with two .NET Framework data providers: the .NET Framework Data Provider for SQL Server and the .NET Framework Data Provider for OLE DB.

The following diagram illustrates the components of ADO.NET architecture.

ADO.NET architecture

Remoting or Marshaling Data between Tiers and Clients

The design of the DataSet enables you to easily transport data to clients over the Web using XML Web services, as well as allowing you to marshal data between .NET components using .NET Remoting services. You can also remote a strongly typed DataSet in this fashion. For an overview of XML Web services, see XML Web Services Overview. For an example of consuming a DataSet from an XML Web service, see Consuming a DataSet from an XML Web Service.

An overview of remoting services can be found in the .NET Remoting Overview. Note that DataTable objects can also be used with remoting services, but cannot be transported via an XML Web service.

ADO.NET Platform Requirements

The Microsoft .NET Framework SDK (including ADO.NET) is supported on Microsoft® Windows® 2000, Microsoft® Windows NT® 4 with Service Pack 6a, Microsoft® Windows® Millennium Edition, Microsoft® Windows® 98, and Microsoft® Windows® SE. Use of the .NET Framework Data Provider for SQL Server or .NET Framework Data Provider for OLE DB requires the installation of Microsoft Data Access Components version 2.6 or later.

The following code example shows how to include the System.Data namespace in your applications, in order to use ADO.NET.

Imports System.Data
[C#]
using System.Data;

The ADO.NET classes are found in System.Data.dll, and are integrated with the XML classes found in System.Xml.dll. When compiling code that uses the System.Data namespace, reference both System.Data.dll and System.Xml.dll. For an example of compiling an ADO.NET application using a command line compiler, see ADO.NET Sample Application.

Choosing a DataReader or a DataSet

When deciding whether your application should use a DataReader (see Retrieving Data Using the DataReader) or a DataSet (see Creating and Using DataSets), you should consider the type of functionality that your application requires. Use a DataSet to do the following:

• Remote data between tiers or from an XML Web service.
• Interact with data dynamically such as binding to a Windows Forms control or combining and relating data from multiple sources.
• Cache data locally in your application.
• Provide a hierarchical XML view of relational data and use tools like an XSL Transformation or an XML Path Language (XPath) Query on your data. For more information, see XML and the DataSet.
• Perform extensive processing on data without requiring an open connection to the data source, which frees the connection to be used by other clients.

If you do not require the functionality provided by the DataSet, you can improve the performance of your application by using the DataReader to return your data in a forward-only read-only fashion. Although the DataAdapter uses the DataReader to fill the contents of a DataSet (see Populating a DataSet from a DataAdapter), by using the DataReader you can receive performance gains because you will save memory that would be consumed by the DataSet, as well as saving the processing required to create and fill the contents of the DataSet.

See Also

Overview of ADO.NET | Accessing Data with ADO.NET | ADO.NET Sample Application