By Ashish Gidh

Occasionally a new and improved product is such a radical departure from the old product that the similarities are mostly in name. This means that the product is certainly new, but a further examination is needed to determine if it is really improved. This is certainly true of ADO.NET; it may share a name with ADO, but that is where the similarities end.

From the beginning
Everything with both classic ADO and ADO.NET starts with the Connection object. The Connection object represents a unique physical connection to a data source, but this is where the similarities end. While the Connections object differences are more philosophical (i.e., how connections are handled), these differences are vast. In classic ADO, when a connection is created and opened, an application can keep that connection open as long as it wants. As a matter of fact, applications aren’t limited to just one open connection; they can have multiple open connections. But since connections are a finite resource, this approach leaves something to be desired.

ADO.NET takes a different approach to connections. A connection is open only long enough to perform an operation. Once the operation is complete, the Recordset is immediately closed. The results of the command are read into a Dataset where they can be processed while disconnected from the data source. While disconnected processing was possible with classic ADO, ADO was also extremely good at showing the differences between what was possible and what was easy.

The same connection frugality is observed in the way that ADO.NET handles updates. When changes are made to a Dataset, they aren’t immediately reflected in the actual tables because of ADO.NET’s disconnected nature. To make the changes “real,” you need to use a DataAdapter object, which is used to both populate and apply updates from/to Datasets.

ADO.NET’sDataAdapter objects have four methods that are used to retrieve or update data to a data source. These methods include: SelectCommand, InsertCommand, UpdateCommand, and DeleteCommand. The best part about these methods is, once you know the name, you also know what they do.

Say goodbye
In classic ADO, the Recordset was the primary method of accessing data. It was as simple as executing a query, and a Recordset was created with the requested columns from one or more tables. In cases where multiple rows (records) were returned, navigation was accomplished through the use of the move, moveNext, movePrevious, moveLast, or moveFirst methods. Useless, of course, since a forward-only cursor was used, in which case only moveNext, moveLast, and move (if moving forward) are permitted.

In ADO.NET, Recordsets are gone and cursors exist in concept only. They have been replaced by data classes that provide the same functionality. For example, most of the cursors that I used in classic ADO were forward-only, read-only, because I’m one of those developers who believes that it is best to get the input/output over with as soon as possible. With the advent of ADO.NET, instead of the forward-only, read-only cursor, a DataReader object provides the same functionality.

New and improved
Arguably the most hyped feature of ADO.NET is its disconnected method of data access. But this is also one of the most misunderstood features. At my current assignment at an ASP shop, there were some meetings that became shouting matches whenever .NET was mentioned.

Why the outcry? Well, somehow the idea that a Dataset resides in memory was interpreted as, “The entire database is stored in memory on the client’s machine.” It took some time to dispel this myth, but in the end, the protesters were convinced that ADO.NET and ASP.NET don’t work that way unless, of course, you want them to.

The in-memory nature of ADO.NET objects is a strength. It provides the ability to manipulate data in ways that are difficult, if not impossible, in classic ADO. ADO.NET and XML are now integrated, and, where with classic ADO it is relatively easy to produce an XML document using an ADO Recordset, the reverse isn’t nearly as easy. A significant amount of code is required to produce an ADO Recordset from an XML document. But because of the integration between ADO.NET and XML, going back and forth from one to another is a matter of using the XmlDataDocument.

This integration with XML isn’t useful only in converting to and from XML; it also provides the opportunity to treat a Dataset as if it were XML. XSLT, XPath, and XQuery can be used with the Dataset, allowing a number of options that require some convoluted code in classic ADO.

Beyond the hype
The hype around ADO.NET is obscuring the fact that it isn’t really an upgrade of classic ADO—it’s an entirely new product with a recycled name. A large number of people who are currently using classic ADO will be put off by ADO.NET’s overwhelming number of choices in how to access information and what to do with information once it has been accessed. But I think the more flexible ADO.NET will eventually replace classic ADO, so resistance is futile.