The Connected Objects
The connected part
represents the objects that insist on having an open connection available for
them to work and interact with the data source. Under the connected part of
ADO.NET, there are the following main objects:Connection: This is the object that
allows you to establish a connection with the data source. Depending on the
actual .NET data provider involved, connection objects automatically pool
physical database connections for you. It’s important to realize that they don’t
pool connection object instances, but they try and recycle physical database
Examples of connection
objects are OleDbConnection, SqlConnection, OracleConnection,
and so on.
Transaction: There are
times when you would want to execute a group of commands together as a group or
as an atomic operation, as an “all-or-nothing” execution. An example might be a
banking application where a credit must not occur if a corresponding debit
cannot be done. Transaction objects let you group together such groups of
commands and execute them atomically. Examples of transaction objects are
OleDbTransaction, SqlTransaction, OracleTransaction, and so on. In ADO.NET 2.0,
you also have the ability to run distributed transactions and enlist in
nondatabase transactions via the System.Transactions namespace. In ADO.NET 1.0
and 1.1, this was possible as a less than ideal solution using the
DataAdapter: This object
acts as a gateway between the disconnected and connected flavors of ADO.NET. It
establishes the connection for you or, given an established connection, it has
enough information specified to itself to enable it to understand a
disconnected object’s data and act upon the database in a prespecified manner.
Examples of DataAdapters are SqlDataAdapter, OracleDataAdapter, and so on.
Command: This object represents an
executable command on the underlying data source.
This command may or may
not return any results. These commands can be used to manipulate existing data,
query existing data, and update or even delete existing data. In addition,
these commands can be used to manipulate underlying table structures. Examples
of command objects are SqlCommand, OracleCommand, and so on.
Parameter: A command needs to be able
to accept parameters. This allows commands to be more flexible and
accept input values and act accordingly. These parameters could be input/output or return
values of stored procedures, or “?” arguments passed to a SQL query, or simply named
parameters to a dynamic query. Examples of parameters are SqlParameter,
OracleParameter, and so on.
DataReader: The DataReader object is
the equivalent of a read-only/forward-only firehose cursor that allows you to
fetch data from a database at an extremely high speed but in a forward-only and