2007/12/12

ADO.NET Overview

ADO.NET Overview

ADO.NET is more than just a thin veneer over some existing API. The similarity to ADO is fairly minimal—the classes and methods of accessing data are completely different.
ADO (ActiveX Data Objects) is a library of COM components that has had many incarnations over the last few years. Currently at version 2.7, ADO consists primarily of the Connection, Command, Recordset, and Field objects. Using ADO, a connection is opened to the database, some data isselected into a record set consisting of fields, that data is then manipulated and updated on the server,and the connection isclosed. ADO also introduced a so-called disconnected record set, which is usedwhen keeping the connection open for long periods of time is not desirable.
There were several problems that ADO did not address satisfactorily, most notably the unwieldiness (inphysical size) of a disconnected recordset. This support was more necessary than ever with the evolutionof Web-centric computing, so a fresh approach was required. There are a number of similarities betweenADO.NET programming and ADO (not only the name), so upgrading from ADO shouldn’t be too difficult.
What’s more, if you’re using SQL Server, there’s a fantastic new set of managed classes that are
tuned to squeeze maximum performance out of the database. This alone should be reason enough to
migrate to ADO.NET.
ADO.NET ships with four database client namespaces: one for SQL Server, another for Oracle, the thirdfor ODBC datasources, and the fourth for any database exposed through OLEDB. If your database ofchoice is not SQL Server or Oracle then the OLEDB route should be taken unless you have no other choice than to use ODBC.

Namespaces
All of the examples in this chapter access data in one way or another. The following namespaces expose

the classes and interfaces used in .NET data access:
❑ System.Data—All generic data access classes
❑ System.Data.Common—Classes shared (or overridden) by individual data providers
❑ System.Data.Odbc—ODBC provider classes
❑ System.Data.OleDb—OLE DB provider classes
❑ System.Data.Oracle—Oracle provider classes
❑ System.Data.SqlClient—SQL Server provider classes
❑ System.Data.SqlTypes—SQL Server data types

The main classes in ADO.NET are listed in the following subsections.
Shared ClassesADO.NET contains a number of classes that are used regardless of whether you are using the SQL Server classes or the OLE DB classes.

The following classes are contained in the System.Data namespace:

❑ DataSet—This object is designed for disconnected use and can contain a set of DataTables
and include relationships between these tables.
❑ DataTable—Acontainer of data that consists of one or more DataColumns and, when populated,will have one or more DataRows containing data.
❑ DataRow—Anumber of values, akin to a row from a database table, or a row from a spreadsheet.
❑ DataColumn—This object contains the definition of a column, such as the name and data type.
❑ DataRelation—Alink between two DataTable classes within a DataSet class. Used for foreign
key and master/detail relationships.
❑ Constraint—This class defines a rule for a DataColumn class (or set of data columns), such as
unique values.
The following classes can be found in the System.Data.Common namespace:
❑ DataColumnMapping—Maps the name of a column from the database with the name of a column within a DataTable.
❑ DataTableMapping—Maps a table name from the database to a DataTable within a DataSet.
Database-Specific Classes In addition to the shared classes introduced in the previous section, ADO.NET contains a number of database-specific classes. These classes implement a set of standard interfaces defined within the System.Data namespace, allowing the classes to be used in a generic manner if necessary. For example, both the SqlConnection and OleDbConnection classes implement the IDbConnection interface.
❑ SqlCommand, OleDbCommand, OracleCommand, and ODBCCommand—Used as wrappers for SQL statements or stored procedure calls.
❑ SqlCommandBuilder, OleDbCommandBuilder, OracleCommandBuilder, and
ODBCCommandBuilder—Used to generate SQL commands (such as INSERT, UPDATE, and
DELETE statements) from a SELECT statement.
❑ SqlConnection, OleDbConnection, OracleConnection, ODBCConnection—Used to connect
to the database. Similar to an ADO Connection.
❑ SqlDataAdapter, OleDbDataAdapter, OracleDataAdapter, ODBCDataAdapter—Used to
hold select, insert, update, and delete commands, which are then used to populate a DataSet
and update the Database.
❑ SqlDataReader, OleDbDataReader, OracleDataReader, ODBCDataReader—Used as a forward
only, connected data reader.
❑ SqlParameter, OleDbParameter, OracleParameter, ODBCParameter—Used to define a
parameter to a stored procedure.
❑ SqlTransaction, OleDbTransaction, OracleTransaction, ODBCTransaction—Used for a
database transaction, wrapped in an object.
As can be seen from the previous list, there are four classes for each type of object—one for each of the

providers that are part of .NET version 1.1. In the rest of this chapter, unless otherwise stated, the prefix
is used to indicate that the particular class used is dependant on the database provider in use.
The most important new feature of the ADO.NET classes is that they are designed to work in a disconnected
manner, which is important in today’s highly Web-centric world. It is now common practice to
architect a service (such as an online bookshop) to connect to a server, retrieve some data, and then work

Data Access with .NET
on that data on the client before reconnecting and passing the data back for processing. The disconnectednature of ADO.NET enables this type of behavior.ADO 2.1 introduced the disconnected record set, which would permit data to be retrieved from adatabase, passed to the client for processing, and then reattached to the server. This used to be cumbersome
to use, because disconnected behavior was not part of the original design. The ADO.NET classes
are different—in all but one case (the DataReader) they are designed for use offline from the database.
The classes and interfaces used for data access in.NET Framework are introduced in the course of this chapter. The focus is mainly on the SQL classes when connecting to the database, because the Framework SDK samples install an MSDE database (SQL Server). In most cases the OleDb, Oracle and ODBC classes mimic exactly the SQL code

No comments: