Introduction

ADO.NET is one of the jewels of the .NET framework. ADO.NET is a revision to ADO that emphasizes disconnected database programming. The reason for this is straightforward and the argument is valid. In the connected database model, a programmer obtains a handle to a database and holds it while performing operations against the database. This causes a problem related to the finite number of connections and the maintenance of those connections in a disconnected space, specifically the World Wide Web. The Web itself is disconnected in the sense that it uses a request-and-response model in which requests are made, the Web server responds, and in between there is a very loose relationship between the client (your browser) and the server (for example, IIS or Apache).

The number of simultaneous connections on the Web can be huge because the servers don't have to track the client connections and the browsers aren't holding onto something that the servers necessarily have to actively manage. Think of ordering lunch at the drive-through window of a fast food restaurant: you drive up, order and collect your food, and drive away ”and the restaurateur's job is done. (Like browsing some Web sites, occasionally the service is a bit unsettling.) We know that this request-and-response model supports servicing a tremendous number of requests.

Because we are moving into a future where the number of users of an application ” especially a Web application ”may be huge, we need real tools that address this reality. With the revision to ADO Microsoft has disconnected the data from the database connection. With ADO.NET you make a request to the database. The database services the request, and the connection is dropped until the next request is made. There are a couple of practical concerns, but the educational literature and my own experience mitigate them.

The biggest concern is that if the data is disconnected, how can a record lock prevent someone else from changing the record? The answer is that technically records cannot be locked and some other user could change your data. The way you manage this problem is by writing WHERE predicates that ensure that your data has not been changed by some other user. For instance, using pseudo-code, you might write "Update my row with new values where some unique value equals a known value." Commonly the known value is some kind of auditing information, perhaps a date and time stamp. Record locks introduced difficulties of their own too.

ADO.NET facilitates massive application scalability because more users can be serviced if information about the user does not have to be maintained in the form of a connection and record locks.

You can read about design goals for ADO.NET in the .NET Framework Developer's Guide (the Visual Studio .NET help documentation). In general, other goals included leveraging current ADO technology, supporting the N-Tier programming model, and incorporating XML. You will find many similarities and parallels between ADO and ADO.NET, and what you know about writing SQL still applies. N-Tier programming is more clearly supported; you can even generalize ADO.NET classes to make typed ADO.NET data objects. Finally, XML is integral to ADO.NET. The result is that the meaning of what a database is will continue to evolve to include persistence entities that include and extend beyond just traditional databases.

This chapter discusses how to employ ADO.NET in a manner consistent with the most general use, which is to read and manage data from a traditional database. (Chapter 12 covers some advanced topics, including the use of stored procedures, transaction processing, and some additional benefits of XML in ADO.NET.)