Datasheet

In addition to all of the great advancements ADO made, it too had some shortcomings, of course. For
example, even though it supported working with disconnected data, this was somewhat cumbersome.
For this reason, many developers never chose to use this feature, while many others never even knew it
existed. This standard practice of leaving the connection open resulted in heavier loads placed on the
database server.
The developers who did choose to close the connection immediately after retrieving the data faced
another problem: having to continually create and destroy connections in each method that needed to
access data. This is a very expensive operation without the advantages of connection pooling that
ADO.NET offers; and as a result, many best practice articles were published advising users to leave a
single connection object open and forward it on to all the methods that needed to access data.
ADO.NET
With the release of the .NET Framework, Microsoft introduced a new data access model, called ADO.NET.
The ActiveX Data Object acronym was no longer relevant, as ADO.NET was not ActiveX, but Microsoft
kept the acronym due to the huge success of ADO. In reality, it’s an entirely new data access model
written in the .NET Framework.
ADO.NET supports communication to data sources through both ODBC and OLE-DB, but it also offers
another option of using database-specific data providers. These data providers offer greater performance
by being able to take advantage of data-source-specific optimizations. By using custom code for the data
source instead of the generic ODBC and OLE-DB code, some of the overhead is also avoided. The original
release of ADO.NET included a SQL provider and an OLE-DB provider, with the ODBC and Oracle
providers being introduced later. Many vendors have also written providers for their databases since.
Figure 1.5 shows the connection options available with ADO.NET.
Figure 1-5
Application
ADO.NET
OLE DB ODBC
Data Store
10
Chapter 1
03_584375 ch01.qxd 10/28/05 10:49 PM Page 10