C H A P T E R 21
ADO.NET Part I: The Connected
Layer
The .NET platform defines a number of namespaces that allow you to interact with relational database
systems. Collectively speaking, these namespaces are known as ADO.NET. In this chapter, you’ll learn
about the overall role of ADO.NET, then move on to the topic of ADO.NET data providers. The .NET
platform supports numerous data providers, each of which is optimized to communicate with a specific
database management system (e.g., Microsoft SQL Server, Oracle, and MySQL).
After you understand the common functionality provided by various data providers, you will then
look at the data provider factory pattern. As you will see, using types within the System.Data.Common
namespace (and a related App.config file), you can build a single code base that can dynamically pick
and choose the underlying data provider without the need to recompile or redeploy the application’s
code base.
Perhaps most importantly, this chapter will give you the chance to build a custom data access
library assembly (AutoLotDAL.dll) that encapsulates various database operations performed on a
custom database named AutoLot. You will expand this library in Chapters 23 and 24 and leverage it over
many of this book’s remaining chapters. Finally, you will wrap things up by examining the topic of
database transactions.
A High-Level Definition of ADO.NET
If you have a background in Microsoft’s previous COM-based data access model (Active Data Objects, or
ADO), you need to understand that ADO.NET has little to do with ADO beyond the letters A, D, and O.
While it is true that there is some relationship between the two systems (e.g., each has the concept of
connection and command objects), some familiar ADO types (e.g., the Recordset) no longer exist.
Furthermore, you can find many new ADO.NET types that have no direct equivalent under classic ADO
(e.g., the data adapter).
Unlike classic ADO, which was primarily designed for tightly coupled client/server systems,
ADO.NET was built with the disconnected world in mind, using DataSets. This type represents a local
copy of any number of related data tables, each of which contains a collection of rows and column.
Using the DataSet, the calling assembly (such as a web page or desktop executable) is able to manipulate
and update a DataSet’s contents while disconnected from the data source, and send any modified data
back for processing using a related data adapter.
From a programmatic point of view, the bulk of ADO.NET is represented by a core assembly named
System.Data.dll. Within this binary, you find a good number of namespaces (see Figure 21-1), many of
which represent the types of a particular ADO.NET data provider (defined momentarily).
801