What Is ADO.NET?

ADO.NET is the name for the set of classes you use with C# and the .NET Framework to access data in a relational, table-oriented format. This includes relational databases such as Microsoft SQL Server and Microsoft Access, as well as other databases and even nonrelational data sources. ADO.NET is integrated into the .NET Framework and is designed to be used with any .NET language, especially C#.

ADO.NET includes all of the System.Data namespace and its nested namespaces such as System. Data.SqlClient and System.Data.OleDb, plus some specific data-related classes from the System. Xml namespace. You looked at XML in Chapter 23; in this chapter you see ADO.NET's support for XML. Physically, the ADO.NET classes are contained in the System.Data.dll assembly and related System. Data.xxx.dll assemblies, again with some exceptions such as XML.

Why Is It Called ADO.NET?

You might ask, why does this part of the .NET Framework get its own weird moniker, ADO.NET? Why not just call it System.Data and be done with it? ADO.NET takes its name from ADO (ActiveX Data Objects), a widely used set of classes used for data access in the previous generation of Microsoft technologies. The ADO.NET name is used because Microsoft wants to make it clear that this is the preferred data access interface in the .NET programming environment.

ADO.NET serves the same purpose as ADO, providing an easy-to-use set of classes for data access, updated and enhanced for the .NET programming environment. While it fulfills the same role as ADO, the classes, properties, and methods in ADO.NET are quite different from those in ADO.

If you are interested in more details of how this developed historically and where it fits in with other Microsoft database interfaces such as ODBC and OLE DB, see the following brief history. Otherwise, skip to the next section to start learning about ADO.NET!

A (Very) Brief History of Data Access

When the first database systems, such as Oracle and IBM's DB2, were written, any developers who wanted their programs to access the data in them needed to use sets of functions that were specific to that database system. Each system had its own library of functions, such as the Oracle Call Interface (OCI) for Oracle, or DBLib for Sybase's SQL Server (later bought by Microsoft). This allowed the programs to have fast access to the data, because their programs communicated directly with the database. However, it meant that programmers had to be familiar with a different library for every database they worked with, so the task of writing data-driven applications was very complicated. It also meant that if a company changed the database system it used, its applications had to be completely rewritten.

This problem was solved by Open Database Connectivity (ODBC). ODBC was developed by Microsoft in collaboration with other companies in the early 1990s. ODBC provided a common set of functions that developers could use against any database system. These functions were translated into database- specific function calls by drivers for that specific database system.

This solved the main problems of the proprietary database libraries — developers only needed to know how to use one set of functions (the ODBC functions), and if a company changed its database system, all it needed to change in its applications was the code to connect to the database. However, there was still one problem. While the paperless office is still largely a myth, companies do have a vast amount of electronic data stored in a whole variety of places — e-mails, Web pages, Project 2000 files, and so on. ODBC was fine for accessing data in traditional databases, but it couldn't access other types of data, which aren't stored in nice neat columns and rows and don't necessarily have a coherent structure at all.

The answer to this problem was provided by OLE DB. OLE DB works in a similar way to ODBC, providing a layer of abstraction between the database and applications that need access to the data. Client applications communicate with the data source, which can be a traditional database or any other place where data is held, through an OLE DB provider for that data source. Data from any source is exposed to the application in table format — just as if it came from a database. And because OLE DB allowed access to data exposed by the existing ODBC drivers, it could be used to access all the databases supported by ODBC. As you will see shortly, ADO.NET supports both OLE DB and ODBC in a very similar way.

The last legacy data access technology to mention is ActiveX Data Objects (ADO). ADO is simply a thin layer, which sits on top of OLE DB, and allows programs written in high-level languages such as Visual Basic to access OLE DB data.

Design Goals of ADO.NET

Let's quickly look at the design goals of ADO.NET. These include:

• Simple access to relational and nonrelational data

• Extensibility to support even more data sources than its predecessor technologies

• Support for multitier applications across the Internet

• Unification of XML and relational data access

Simple Access to Relational Data

The primary goal of ADO.NET is to provide simple access to relational data. Straightforward, easy-to-use classes represent the tables, columns, and rows within relational databases. Additionally, ADO.NET introduces the DataSet class, which represents a set of data from related tables encapsulated as a single unit, preserving the integrity of the relationships between them. This is a new concept in ADO.NET that significantly extends the capabilities of the data access interface.

Extensibility

ADO.NET is extensible — it provides a framework for plug-in .NET data providers (also called managed providers) that can be built to read and write data from any data source. ADO.NET comes with several built-in .NET data providers, including one for the Microsoft SQL Server database, one for Oracle, one each for the generic database interfaces ODBC (the Microsoft Open DataBase Connectivity database API) and OLE DB (Microsoft's COM-based Object Linking and Embedding DataBase API). Almost every database and data file format has an ODBC or OLE DB provider available for it, including Microsoft Access, third-party databases, and nonrelational data; thus, ADO.NET can be used to interface to almost any database or data format through one of the built-in data providers. Many database vendors such as MySQL and Oracle also provide native .NET data providers for their offerings.

Support for Multitier Applications

ADO.NET is designed for multitier applications. This is the most common architecture today for business and e-commerce applications. In multitier architecture, different parts of the application logic are separated into layers, or tiers, and communicate only with the layer around them.

One of the most common approaches is the 3-tier model, which consists of the following:

• Data tier: Contains the database and data access code.

• Business tier: Contains the business logic, which defines the unique functionality of this application, and abstracts this away from other tiers. This tier is sometimes referred to as the middle tier.

• Presentation tier: Provides the user interface and control of process flow to the application, as well as such things as the validation of user input.

ADO.NET uses the open Internet-standard XML format for communications between the tiers, allowing data to pass through Internet firewalls and allowing the possibility of a non-Microsoft implementation of one or more tiers.

Unification of XML and Relational Data Access

Another important goal of ADO.NET is to provide a bridge between relational data in rows and columns, and XML documents, which have a hierarchical data structure. the .NET technology is built around XML, and ADO.NET makes extensive use of it.

Now that you've seen what ADO.NET's goals are, let's look at the actual ADO.NET classes themselves.