Why ADO.NET Was Designed

As mentioned, each previous data access technology has its own pros and cons. Some of them were designed specifically for a particular type of data source, some of them aren't easy to program for developers, and some of them don't have good enough performance. For example, the ODBC API is a set of C functions. It has no object-oriented support. So, developing applications using ODBC is a time-consuming process for developers. Another problem with ODBC is its relational nature. The ODBC API is limited to relational databases, and it's difficult to use ODBC with nonrelational data sources such as network directories, email stores, ISAM data, object data, and so on.

DAO is an object model but was specifically designed to work with the Microsoft Jet database engine. The MFC ODBC and DAO classes are one more wrapper for ODBC and DAO APIs. Because of this extra wrapper, these classes aren't up to the mark performance-wise and still have some of the same limitations as ODBC and DAO.

OLE-DB is a solution that works with any kind of data source using OLE-DB providers and consumers; however, writing OLE-DB applications is time consuming, and it's hard for developers to program them. Moreover, OLE-DB is a flat model. That means you could directly connect to a table without going through hierarchical objects of connections and databases. Because of the lower-level programming model of the OLE API, the OLE-DB API isn't easy to program for non-OLE programmers.

To overcome this problem, Microsoft introduced ADO. ADO is a high-level programming model, and it was the best data access technology at that point. It's a nice COM wrapper for the OLE-DB API, and it suits most developers. The first major drawback of ADO is that it's a COM-based model. Writing COM-based applications and using them is probably one of the most difficult models of programming and a pain for non-COM developers. The second drawback is the limited support for XML. You can read XML documents through ADO, but documents have to have a certain format, which negates many of the benefits of XML.

Keeping all these problems in mind, Microsoft wrote a set of new object-oriented classes: ADO.NET. ADO.NET inherits its programming model from its predecessor ADO, so ADO programmers will see something common between these two APIs. As such, it will also take less time to jump from ADO to ADO.NET. ADO.NET classes are based on the ADO model and have some objects in common, such as Connection and Command. However, DataSets replace recordsets in ADO.NET. These classes are easy to use and have solutions for all the problems mentioned.

In brief, ADO.NET was designed to meet today's programming needs, including disconnected data, tight integration with XML, and a common model to work with all kinds of data sources. Welcome to the ADO.NET world.