http://msdn.microsoft.com/library/de...etprogmsdn.asp
The Design of ADO
To better understand the model and design of ADO.NET, it is helpful to
review some of the core aspects of ADO.
ADO uses a single object, the Recordset, as a common representation for
working with all types of data. The Recordset is used for working with
a forward-only stream of results from a database, for scrolling through
data held on a server, or for scrolling through a set of cached
results. Changes made to data may be applied immediately to the
database, or applied as a batch using optimistic search and update
operations. You specify the desired functionality when you create the
Recordset, and the behavior of the resulting Recordset can vary greatly
depending on the properties you request.
Because ADO uses a single object that can behave in many different
ways, it enables you to keep the object model of your applications very
simple. However, it is difficult to write common, predictable, and
optimized code because the behavior, performance, and semantics
exhibited by that single object can vary greatly depending on how the
object is generated and what data it is accessing. This is particularly
true for generic components (such as a grid control) that attempt to
consume data not generated by the component and for which the component
has no ability to specify required behavior or functionality.
ADO.NET: Explicit and Factored
In designing ADO.NET, consideration was given to the tasks that
developers commonly face when accessing and working with data. Rather
than using a single object to perform a number of tasks, ADO.NET
factors specific functionality into explicit objects that are optimized
to enable developers to accomplish each task.
The functionality that the ADO Recordset provides has been factored
into the following explicit objects in ADO.NET: the DataReader, which
provides fast, forward-only, read-only access to query results; the
DataSet, which provides an in-memory relational representation of data;
and the DataAdapter, which provides a bridge between the DataSet and
the data source. The ADO.NET Command object also includes explicit
functionality such as the ExecuteNonQuery method for commands that do
not return rows, and the ExecuteScalar method for queries that return a
single value rather than a row set.
To better understand how the design of ADO.NET is made up of objects
that are optimized to perform explicit behavior, consider the following
tasks that are common when working with data.
Forward-Only Read-Only Data Streams
Applications, particularly middle-tier applications, often process a
series of results programmaticall y, requiring no user interaction and
no updating of or scrolling back through the results as they are read.
In ADO, this type of data retrieval is performed using a Recordset with
a forward-only cursor and a read-only lock. In ADO.NET, however, the
DataReader object optimizes this type of data retrieval by providing a
non-buffered, forward-only, read-only stream that provides the most
efficient mechanism for retrieving results from the database. Much of
this efficiency is gained as a result of the DataReader having been
designed solely for this purpose, without having to support scenarios
where data is updated at the data source or cached locally as with the
ADO Recordset.
Returning a Single Value
Often the only data to be retrieved from a database is a single value
(for example, an account balance). In ADO, you perform this type of
data retrieval by creating a Recordset object, reading through the
results, retrieving the single value, and then closing the Recordset.
In ADO.NET, however, the Command object supports this function through
the ExecuteScalar method, which returns the single value from the
database without having to introduce an additional object to hold the
results.
Disconnected Access to Data
A frequent case for exposing data is a representation in which a user
can navigate the data in an ad-hoc manner without holding locks or
tying up resources on the server. Some examples of this scenario are
binding data to a control or combining data from multiple data sources
and/or XML. The ADO Recordset provides some support for these
scenarios, using a client-side cursor location. However, in ADO.NET the
DataSet is explicitly designed for such tasks.
The DataSet provides a common, completely disconnected data
representation that can hold results from a variety of different
sources. Because the DataSet is completely independent of the data
source, it provides the same performance and semantics regardless of
whether the data is loaded from a database, loaded from XML, or is
generated by the application. A single DataSet may contain tables
populated from several different databases and other non-database
sources; to the consumer of the DataSet it all looks and behaves
exactly the same. Within the DataSet you can define relations to
navigate from a table populated from one database (for example,
"Customers" ), to a related table populated from an entirely different
database (for example, "Orders"), and from there to a third table (for
example, "OrderDetai ls") containing values loaded from XML. The
relational capabilities of the DataSet provide an advantage over the
Recordset, which is limited to exposing the results from multiple
tables either as a single joined result, or by returning multiple
distinct result sets, requiring the developer to handle and relate the
results manually. Though the Recordset has the ability to return and
navigate hierarchical results (using the MSDataShape provider), the
DataSet provides much greater flexibility when dealing with related
result sets. The DataSet also provides the ability to transmit results
to and from a remote client or server in an open XML format, with the
schema defined using the XML Schema definition language (XSD).
Retrieving and Updating Data from a Data Source
Based on customer feedback and common use cases it is clear that in
most application development scenarios (with the exception of ad-hoc
tools and generic data components) the developer knows certain things
about the data at design time that technologies like ADO attempt to
derive at run time. For example, in most middle-tier applications the
developer knows, at the time of application development, the type of
database to be accessed, what queries will be executed, and how the
results will be returned. ADO.NET gives you the ability to apply this
knowledge at design time in order to provide better run-time
performance and predictability.
As an example, when using batch updating with ADO Recordset objects,
you must submit changes to the database by executing appropriate
INSERT, UPDATE, and DELETE statements for each row that has changed.
ADO generates these statements implicitly, at run time, based on
metadata that is often expensive to obtain. ADO.NET, however, enables
you to explicitly specify INSERT, UPDATE, and DELETE commands, as well
as custom business logic such as a stored procedure, that will be used
to resolve changes in a DataSet back to the data source using the
DataAdapter. This model provides you with greater control over how
application data is returned and updated, and removes the expense of
gathering the metadata at run time.
The DataAdapter provides the bridge between the DataSet and the data
source. A DataAdapter is used to populate a DataSet with results from a
database, and to read changes out of a DataSet and resolve those
changes back to the database. Using a separate object, the DataAdapter,
to communicate with the database allows the DataSet to remain
completely generic with respect to the data it contains, and gives you
more control over when and how commands are executed and changes are
sent to the database. ADO performs much of this behavior implicitly,
however the explicit design of ADO.NET enables you to fine-tune your
interaction with a data source for best performance and scalability.
The implicit update behavior of ADO is also available in ADO.NET using
a CommandBuilder object that, based on a single table SELECT,
automatically generates the INSERT, UPDATE, and DELETE commands used
for queries by the DataAdapter. However, the compromise for this
convenience is slower performance and less control over how changes are
propagated to the data source because, as with ADO, the commands are
generated from metadata collected at run time.
Data Types
In ADO, all results are returned in a standard OLE Automation Variant
type. This can hinder performance because, in addition to conversion
overhead, variants are allocated using task-allocated system memory,
which causes contention across the system. When retrieving results from
a DataReader in ADO.NET, however, you can retrieve columns in their
native data type, as a common Object class, without going through
expensive conversions. Data values can either be exposed as .NET
Framework types, or can be placed in a proprietary structure in the
..NET Framework to preserve the fidelity of the native type. An example
of this is the SQL Server .NET Data Provider, which can be used to
expose Microsoft® SQL Server™ data as .NET Framework types, or as
proprietary types defined by the classes in the System.Data.Sql Types
namespace.
Summary
ADO.NET is designed to build on the strength of the ADO programming
model, while providing an evolution of data access technology to meet
the changing needs of the developer. It is designed to leverage your
existing knowledge of ADO, while giving you much finer control over the
components, resources, and behavior of your applications when accessing
and working with data.
The Design of ADO
To better understand the model and design of ADO.NET, it is helpful to
review some of the core aspects of ADO.
ADO uses a single object, the Recordset, as a common representation for
working with all types of data. The Recordset is used for working with
a forward-only stream of results from a database, for scrolling through
data held on a server, or for scrolling through a set of cached
results. Changes made to data may be applied immediately to the
database, or applied as a batch using optimistic search and update
operations. You specify the desired functionality when you create the
Recordset, and the behavior of the resulting Recordset can vary greatly
depending on the properties you request.
Because ADO uses a single object that can behave in many different
ways, it enables you to keep the object model of your applications very
simple. However, it is difficult to write common, predictable, and
optimized code because the behavior, performance, and semantics
exhibited by that single object can vary greatly depending on how the
object is generated and what data it is accessing. This is particularly
true for generic components (such as a grid control) that attempt to
consume data not generated by the component and for which the component
has no ability to specify required behavior or functionality.
ADO.NET: Explicit and Factored
In designing ADO.NET, consideration was given to the tasks that
developers commonly face when accessing and working with data. Rather
than using a single object to perform a number of tasks, ADO.NET
factors specific functionality into explicit objects that are optimized
to enable developers to accomplish each task.
The functionality that the ADO Recordset provides has been factored
into the following explicit objects in ADO.NET: the DataReader, which
provides fast, forward-only, read-only access to query results; the
DataSet, which provides an in-memory relational representation of data;
and the DataAdapter, which provides a bridge between the DataSet and
the data source. The ADO.NET Command object also includes explicit
functionality such as the ExecuteNonQuery method for commands that do
not return rows, and the ExecuteScalar method for queries that return a
single value rather than a row set.
To better understand how the design of ADO.NET is made up of objects
that are optimized to perform explicit behavior, consider the following
tasks that are common when working with data.
Forward-Only Read-Only Data Streams
Applications, particularly middle-tier applications, often process a
series of results programmaticall y, requiring no user interaction and
no updating of or scrolling back through the results as they are read.
In ADO, this type of data retrieval is performed using a Recordset with
a forward-only cursor and a read-only lock. In ADO.NET, however, the
DataReader object optimizes this type of data retrieval by providing a
non-buffered, forward-only, read-only stream that provides the most
efficient mechanism for retrieving results from the database. Much of
this efficiency is gained as a result of the DataReader having been
designed solely for this purpose, without having to support scenarios
where data is updated at the data source or cached locally as with the
ADO Recordset.
Returning a Single Value
Often the only data to be retrieved from a database is a single value
(for example, an account balance). In ADO, you perform this type of
data retrieval by creating a Recordset object, reading through the
results, retrieving the single value, and then closing the Recordset.
In ADO.NET, however, the Command object supports this function through
the ExecuteScalar method, which returns the single value from the
database without having to introduce an additional object to hold the
results.
Disconnected Access to Data
A frequent case for exposing data is a representation in which a user
can navigate the data in an ad-hoc manner without holding locks or
tying up resources on the server. Some examples of this scenario are
binding data to a control or combining data from multiple data sources
and/or XML. The ADO Recordset provides some support for these
scenarios, using a client-side cursor location. However, in ADO.NET the
DataSet is explicitly designed for such tasks.
The DataSet provides a common, completely disconnected data
representation that can hold results from a variety of different
sources. Because the DataSet is completely independent of the data
source, it provides the same performance and semantics regardless of
whether the data is loaded from a database, loaded from XML, or is
generated by the application. A single DataSet may contain tables
populated from several different databases and other non-database
sources; to the consumer of the DataSet it all looks and behaves
exactly the same. Within the DataSet you can define relations to
navigate from a table populated from one database (for example,
"Customers" ), to a related table populated from an entirely different
database (for example, "Orders"), and from there to a third table (for
example, "OrderDetai ls") containing values loaded from XML. The
relational capabilities of the DataSet provide an advantage over the
Recordset, which is limited to exposing the results from multiple
tables either as a single joined result, or by returning multiple
distinct result sets, requiring the developer to handle and relate the
results manually. Though the Recordset has the ability to return and
navigate hierarchical results (using the MSDataShape provider), the
DataSet provides much greater flexibility when dealing with related
result sets. The DataSet also provides the ability to transmit results
to and from a remote client or server in an open XML format, with the
schema defined using the XML Schema definition language (XSD).
Retrieving and Updating Data from a Data Source
Based on customer feedback and common use cases it is clear that in
most application development scenarios (with the exception of ad-hoc
tools and generic data components) the developer knows certain things
about the data at design time that technologies like ADO attempt to
derive at run time. For example, in most middle-tier applications the
developer knows, at the time of application development, the type of
database to be accessed, what queries will be executed, and how the
results will be returned. ADO.NET gives you the ability to apply this
knowledge at design time in order to provide better run-time
performance and predictability.
As an example, when using batch updating with ADO Recordset objects,
you must submit changes to the database by executing appropriate
INSERT, UPDATE, and DELETE statements for each row that has changed.
ADO generates these statements implicitly, at run time, based on
metadata that is often expensive to obtain. ADO.NET, however, enables
you to explicitly specify INSERT, UPDATE, and DELETE commands, as well
as custom business logic such as a stored procedure, that will be used
to resolve changes in a DataSet back to the data source using the
DataAdapter. This model provides you with greater control over how
application data is returned and updated, and removes the expense of
gathering the metadata at run time.
The DataAdapter provides the bridge between the DataSet and the data
source. A DataAdapter is used to populate a DataSet with results from a
database, and to read changes out of a DataSet and resolve those
changes back to the database. Using a separate object, the DataAdapter,
to communicate with the database allows the DataSet to remain
completely generic with respect to the data it contains, and gives you
more control over when and how commands are executed and changes are
sent to the database. ADO performs much of this behavior implicitly,
however the explicit design of ADO.NET enables you to fine-tune your
interaction with a data source for best performance and scalability.
The implicit update behavior of ADO is also available in ADO.NET using
a CommandBuilder object that, based on a single table SELECT,
automatically generates the INSERT, UPDATE, and DELETE commands used
for queries by the DataAdapter. However, the compromise for this
convenience is slower performance and less control over how changes are
propagated to the data source because, as with ADO, the commands are
generated from metadata collected at run time.
Data Types
In ADO, all results are returned in a standard OLE Automation Variant
type. This can hinder performance because, in addition to conversion
overhead, variants are allocated using task-allocated system memory,
which causes contention across the system. When retrieving results from
a DataReader in ADO.NET, however, you can retrieve columns in their
native data type, as a common Object class, without going through
expensive conversions. Data values can either be exposed as .NET
Framework types, or can be placed in a proprietary structure in the
..NET Framework to preserve the fidelity of the native type. An example
of this is the SQL Server .NET Data Provider, which can be used to
expose Microsoft® SQL Server™ data as .NET Framework types, or as
proprietary types defined by the classes in the System.Data.Sql Types
namespace.
Summary
ADO.NET is designed to build on the strength of the ADO programming
model, while providing an evolution of data access technology to meet
the changing needs of the developer. It is designed to leverage your
existing knowledge of ADO, while giving you much finer control over the
components, resources, and behavior of your applications when accessing
and working with data.
Comment