Database Reference
In-Depth Information
With the multilayered data access model and the connected nature of ADO, you could easily end up
sapping server resources and creating a performance bottleneck. ADO served well in its time, but
ADO.NET has some great features that make it a far superior data access technology.
ADO.NET Isn't a New Version of ADO
ADO.NET is a completely new data access technology, with a new design that was built entirely from
scratch. Let's first get this cleared up: ADO.NET
doesn't
stand for ActiveX Data Objects .NET. Why? For
many reasons, but the following are the two most important ones:
•
ADO.NET is an integral part of .NET, not an external entity.
•
ADO.NET isn't a collection of ActiveX components.
The name ADO.NET is analogous to ADO because Microsoft wanted developers to feel at home
using ADO.NET and didn't want them to think they'd need to “learn it all over again,” as mentioned
earlier, so Microsoft purposely named and designed ADO.NET to offer similar features implemented in a
different way.
During the design of .NET, Microsoft realized that ADO wasn't going to fit in. ADO was available as
an external package based on Component Object Model (COM) objects, requiring .NET applications to
explicitly include a reference to it. In contrast, .NET applications are designed to share a single model,
where all libraries are integrated into a single framework, organized into logical namespaces, and
declared public to any application that wants to use them. It was wisely decided that the .NET data
access technology should comply with the .NET architectural model. So, ADO.NET was born.
ADO.NET is designed to accommodate both connected and disconnected access. Also, ADO.NET
embraces the fundamentally important XML standard, much more than ADO did, since the explosion in
XML use came about after ADO was developed. With ADO.NET, not only can you use XML to transfer
data between applications, but you can also export data from your application into an XML file, store it
locally on your system, and retrieve it later when you need it.
Performance usually comes at a price, but in the case of ADO.NET, the price is definitely reasonable.
Unlike ADO, ADO.NET doesn't transparently wrap OLE DB providers; instead, it uses
managed data
providers
that are designed specifically for each type of data source, thus leveraging their true power and
adding to overall application speed and performance.
ADO.NET also works in both connected and disconnected environments. You can connect to a
database, remain connected while simply reading data, and then close your connection, which is a
process similar to ADO. Where ADO.NET really begins to shine is in the disconnected world. If you need
to edit database data, maintaining a continuous connection would be costly on the server. ADO.NET
gets around this by providing a sophisticated disconnected model. Data is sent from the server and
cached locally on the client. When you're ready to update the database, you can send the changed data
back to the server, where updates and conflicts are managed for you.
In ADO.NET, when you retrieve data, you use an object known as a
data reader.
When you work
with disconnected data, the data is cached locally in a relational data structure, either a
data table
or a
data set.
ADO.NET and the .NET Base Class Library
A data set (a
DataSet
object) can hold large amounts of data in the form of tables (
DataTable
objects),
their relationships (
DataRelation
objects), and constraints (
Constraint
objects) in an in-memory cache,
which can then be exported to an external file or to another data set. Since XML support is integrated
into ADO.NET, you can produce XML schemas and transmit and share data using XML documents.
Table 10-1 describes the namespaces in which ADO.NET components are grouped.
