Cositas

Moving from ADO to ADO.NET
Let’s face it—most Microsoft Visual Basic applications have some sort of data access. If your application uses ActiveX Data Objects (ADO), you probably want to know what improvements you can make now that you are upgrading to Visual Basic .NET. The .NET Framework offers a whole new set of controls and services, including ADO.NET. Naturally, you will want to takeadvantage of some or all of these new features. From the developer’s standpoint, you have three options available:
I I I

Adapt your usage of ADO to better interoperate with the .NET Framework objects. Upgrade your ADO code to ADO.NET. Do both.

This chapter introduces the concepts and class hierarchy of ADO.NET. Then it provides an overview of how to use your existing ADO code within your .NETapplication to bind data to controls and support ADO Recordsets with XML Web services. For the more adventurous among you, the last part of this chapter offers some guidance on how to migrate your existing ADO code to ADO.NET.

ADO.NET for the ADO Programmer
It is obvious from the get-go that ADO.NET isn’t the traditional ADO. The data object model provided by ADO.NET is substantially differentfrom that of ADO and requires a different approach when designing and implementing solutions.
417

418

Part IV

Techniques for Adding Value

While some of the concepts remain familiar to ADO developers (such as using Connection and Command objects to manipulate a data source), others will require some adjustment. This discussion gives only a short overview, so we can quickly move on tothe more interesting stuff.

Overview of ADO.NET
While ADO.NET presents a new data object model, parts of it are quite similar to the ADO we all know and love. Think of ADO.NET as the result of the integration of both classic ADO and the Microsoft XML technologies in a single, coherent framework. Unlike ADO, ADO.NET was designed from the ground up to support a more general data architecture thatis abstracted from an underlying database. In other words, ADO.NET was designed to work with a myriad of data sources and can function as a data store in and of itself. This framework provides a series of data container objects that support functions similar to those used in databases (indexing, sorting, and views) without requiring an actual physical database behind the scenes. ADO.NET alsoprovides an interface that is consistent with other .NET stream-based data classes. This is a huge step forward and a wonderful design win. In Visual Basic 6, ADO uses a totally different object model compared to the FileSystemObject or the Microsoft XML libraries. ADO.NET, on the other hand, is designed to be consistent with other .NET Framework classes. This new compatibility enables developers tomove between vastly different kinds of classes with relative ease. Figure 20-1 provides an overview of the ADO.NET class structure.
System.Data Data Classes DataView DataSet DataTable

Connection

Command

DataAdapter

DataReader

Provider-specific data classes (OleDb or SqlClient)
F20km01

Figure 20-1

Overview of ADO.NET classes.

While the Connection and Command objects arestill required for most data access, the distinction between the two objects has been made literal, as the Connection object now solely represents a database connection, while the Command object handles all queries.

Chapter 20

Moving from ADO to ADO.NET

419

The classic ADO Recordset functionality has been split into smaller and more specialized objects: the DataSet and DataReader classes.Forward-only “firehose” Recordsets map directly to DataReaders, while disconnected Recordsets map best to DataSets. DataSet is a powerful new class designed solely to address the disconnected data model problem. It was designed specifically to fill the gaps in the way ADO handles disconnected data, which was never very satisfactory. Given the new kinds of applications that Visual Basic .NET...