ADO.NET Overview

The Web has changed how data is disseminated, managed, and viewed. Instead of a limited number of people within a company accessing and working with corporate data, there are now hundreds of thousands of people who may view data on a Web site in a single day. These changes introduce a need for more scalable systems to keep up with the growing demand on Internet commerce and other sites that present large amounts of data to visitors.

In recognition of this growing trend for scalable information systems, Microsoft introduced an evolution of ActiveX Data Objects technology (ADO), known as ADO.NET. The goal of ADO.NET is to allow existing data management scenarios to exist while introducing new concepts that account for the scalability needs of the Internet.

To achieve scalability, ADO.NET enables sites to operate with disconnected data. This recognizes the fact that many uses of data involve read-only information. If there is no need to perform other operations on data, such as insert, modify, and delete, there is no reason to hold on to database connections, a critical resource directly affecting the scalability of an application.

ADO.NET is gaining momentum as new companies adopt it every day. .NET includes ADO.NET implementations, called Data Providers, for SQL Server, Oracle, OLE DB, and ODBC. Additionally, Borland has built a Borland Data Provider for ADO.NET (BDP.NET), which may be used among multiple databases, including Borland InterBase, Microsoft SQL Server 2000, Oracle9i, and IBM DB2. The open source Mono project is producing numerous ADO.NET Data Providers. As of this writing the Mono project has completed ten, three have been completed by third parties, and several more ADO.NET Data Providers are in the works. Additionally, Raining Data has released the PickDP ADO.NET Data Provider, so .NET applications can be written to access its Multi-Value database environment.

SHOP TALK
BENEFITS OF DISCONNECTED DATA

I learned about the benefit of ADO.NET the first time I built an ASP.NET Web page. I was so proud that I got all the components hooked up and the data was popping up on the screen just as it should. However, as the site moved from test data to higher volume, performance began to fade. It seems that I was making new queries on every postback. Because the data being displayed was primarily read-only, it was a prime candidate for a disconnected solution. Fortunately, it was also small enough that caching was also an option. Because ADO.NET is designed to support disconnected data, the implementation was simple. I just collected the data for the page in a DataSet and kept it in cache. The performance gains were immediate and data pages popped up just as fast as a normal HTML page.