Chapter 1: Overview of ADO.NET

Why a New Object Model?

Developers who have experience with Microsoft's previous data access technology, ActiveX Data Objects (ADO), might ask, "Isn't that what ADO is for? Why has Microsoft built a new data access technology?"

It seems as if each successive version of Visual Basic has introduced users to a new data access model. Visual Basic 3 included Data Access Objects (DAO). Visual Basic 4 introduced developers to Remote Data Objects (RDO). Visual Basic 5 and Visual Studio 97 included ODBCDirect. The previous suite of developer tools, Visual Basic 6 and Visual Studio 6, featured ADO.

Some developers see this constant change as a thinly veiled attempt to sell technical books. Actually, Microsoft has introduced new data access technologies in an ongoing attempt to address developers' data access needs.

DAO was initially designed to communicate with local file-based databases. Soon Visual Basic developers wanted to talk to server-based databases such as Microsoft SQL Server and Oracle. DAO allows developers to communicate with such databases, but developers craved more control and better performance. So the Visual Basic development team created RDO to give developers a fast, lightweight data access layer designed to talk to larger server-based databases. Some developers wanted the power of RDO but did not want to give up the ease of use that DAO provides. Microsoft created ODBCDirect to give them the best of both worlds. Then came the Internet, and developers craved a data access model they could use more easily in server-side scripts, that would require fewer lines of code, and that would allow them to pass data structures from server to client and back. Thus ADO was born.

ADO has served many developers well for the past few years, but it lacks key features that developers need to build more powerful applications. For example, more and more developers want to work with XML data. While recent versions of ADO have added XML features, ADO was not built to work with XML data. For example, ADO does not allow you to separate the schema information from the actual data. Microsoft might add more XML features to future releases of ADO, but ADO will never handle XML data as efficiently as ADO.NET does because ADO.NET was designed with XML in mind and ADO was not. The ADO cursor engine makes it possible to pass disconnected ADO Recordset objects between different tiers in your application, but you cannot combine the contents of multiple Recordset objects. ADO allows you to submit cached changes to databases, but it does not give you control over the logic used to submit updates. Also, the ADO cursor engine does not, for example, provide a way to submit pending changes to your database via stored procedures. Because many database administrators allow users to modify the contents of the database only through stored procedures, many developers cannot submit updates through the ADO Recordset object.

Microsoft built ADO.NET to address these key scenarios, along with others that I'll cover throughout this book.

Like its predecessors, ADO was built for COM-based application development. With the advent of the common language runtime and the .NET Framework, Microsoft has completely overhauled Visual Studio. We now have Microsoft Windows and Web-based forms packages designed to run in the common language runtime. Similarly, Microsoft has designed a new data access object model for the .NET Framework, ADO.NET.

ADO.NET is designed to combine the best features of its predecessors while adding features requested most frequently by developers—greater XML support, easier disconnected data access, more control over updates, and greater update flexibility.