Looking Again at the ADO.NET Object Model

Before we jump in, take a moment to look over Figure 11-1, which shows the ADO.NET object model. The ADO.NET object model has been streamlined significantly so that it is much easier to understand and work with than classic ADO.

ADO.NET is represented in the Microsoft .NET Framework by the namespace System.Data, as well as all of System.Data's child namespaces. ADO.NET's object model is an all-purpose, generalized data access model that's designed to support accessing and writing to a wide variety of data sources.

The data provider communicates with a data source such as a database, an e-mail store, a Microsoft Excel spreadsheet, a text file, and so on. The beauty of the data provider approach is that we have only to configure the data provider and program the uniform DataSet object model. We don't have to worry about how the data gets to the data set. Once it's there, we have a uniform object model that works the same regardless of where the data came from.

Remember that the data provider connects to the data source on behalf of ADO.NET. All of the connections are encapsulated. The data provider has several key objects contained in it, which we looked at briefly in Chapter 10, "Data Access with ADO.NET."

Figure 11-1

The ADO.NET object model.

Connection. Used to connect to the data source. Connection objects are represented by the provider-specific classes SqlConnection and OleDbConnection. Connections are opened either explicitly by calling the Open method on the connection or implicitly by using a DataAdapter.
Command. Contains information that is submitted to a data source as a query. Command objects are represented by the specific classes SqlCommand and OleDbCommand. Functionally, commands travel over connections, and query results are returned in the form of streams, which can then be accessed by a DataReader object or passed into a DataSet object via a DataAdapter.
DataAdapter. Provides a set of methods and properties to retrieve and save data, forming a bridge between a data set and its data source. The DataAdapter encapsulates a set of data commands and a connection that is used to fill a data set as well as to update the data source. The Fill method calls the SELECT command, while the Update method calls INSERT, UPDATE, or DELETE commands for each changed row.
DataReader. Provides methods and properties that deliver a forward only stream of data rows from a data source.

The DataSet object represents a cache of data that contains tables, columns, relationships, and various constraints. While it behaves much like a database, a DataSet object does not interact directly with a database. That is what the data provider is for. As I mentioned, this approach allows a Visual Basic .NET developer to work with a consistent object model, regardless of the source of the data. Data can easily be placed into a DataSet from a database, an XML file, generated code, or user input. The DataSet object's consistent programming model works easily with flat, relational, or hierarchical data storage.

The DataSet tracks changes made to the data it contains before updating the source. You can use the GetChanges method of a DataSet to create a second DataSet that contains only the changes to the original data. The DataSet object holding the changes can be used by a DataAdapter to update the original source.

The DataView object provides methods and properties that enable various user interface objects—such as a data grid—to bind to a data set and view its contents in various meaningful ways. The DataView is really very simple, and we will explore its use later in the chapter. The DataView, however, can be used only in conjunction with a DataSet and never a DataReader.

We wrote a program in Chapter 10 that used the DataReader object, which, as you can see in Figure 11-2, is contained in the data provider. The DataReader is an extreme optimization of the ADO.NET object model because it eliminates the need for a DataSet. By eliminating parts of the ADO.NET object model, it provides lightning fast and efficient data access.

Figure 11-2

The DataReader object.

The ExecuteReader method of the Command object sends the Command.CommandText call to the Connection object. The Connection object then builds the DataReader and sends the result set to the UI via a stream. As I mentioned in the last chapter, be sure to use a DataReader when you need only to display but not update data.