ADO.NET Design Goals

for RuBoard

Before digging into how ADO.NET has been architected, let's take a brief look at the design goals, which provides insight into the final implementation. To that end, ADO.NET was designed with five primary goals in mind.

It Efficiently Supports a Multi-Tiered Programming Model

As mentioned earlier, one of the key shifts in software development in the past several years has been to a multi-tier (or n- tier ) programming model. In that model, data is read from a data source, disconnected from the source, and moved across tiers. If you think of those tiers as not simply machines within an organization, but as Web sites that span organizations (as with XML Web Services), it becomes immediately apparent that the disconnected record sets of ADO 2.x won't satisfy this model. This is the case because a disconnected Recordset is a COM object and, therefore, you need a COM infrastructure on both ends of the channel. Although the COM/DCOM component model has been extremely successful, it is, for all intents and purposes, wedded to the Windows platform. This means that an organization running a different platform (for example, Sun Solaris) can't exchange data through a Recordset . In fact, even two Microsoft shops will have difficulty doing this because firewall configurations often prevent DCOM communication.

To address the disconnected model, the core ADO.NET object is an in-memory XML-based cache called the DataSet . Because the DataSet is a managed class, it can take advantage of the runtime's ability to serialize and deserialize it to XML, thereby allowing it to pass more easily between tiers in a multi-tiered architecture. Because the DataSet is so fundamental, you'll explore it in depth in Days 3, "Working with DataSets," 4, "DataSet Internals," and 5, "Changing Data."

It Deeply Integrates XML Standards

If XML is the primary means of exchanging data over the Web, ADO.NET needs to support it in a robust way. This means that not only should you be able to transform data into XML, but also control the schema and read and write data natively as XML. To that end, the DataSet is a fully XML-enabled object. Its structure is defined by an XSD schema and its data is represented as XML. Further, ADO.NET integrates the way you work with both relational and XML data. In the past, ADO could be used to manipulate relational data, whereas the MSXML parser could be used to manipulate XML documents. Within the .NET Framework, these two models are fundamentally joined. You'll look at this in more detail on Day 7, "DataSets and XML."

It Leverages Current ADO Knowledge

First and foremost, although there's always a little pain when learning a new data access model, the goal was to allow current ADO developers to move into ADO.NET with their current skill sets intact and therefore minimize the learning curve. As a result, you'll find many familiar concepts in ADO.NET, including connection, command, and parameter objects. You'll look at this side of ADO.NET in depth in Week 2.

This is also important because, as you'll see, ADO.NET isn't a wholesale replacement of ADO and OLE DB, but is rightly thought of as an addition to it. ADO.NET, in its current incarnation, targets only a specific set of application scenarios ”that is, Web-based distributed applications ”whereas ADO can still be used to build connected applications that rely on features such as server-side cursors .

Why ADO.NET?

Good question. Officially, the acronym ADO no longer stands for ActiveX Data Objects (the term ActiveX was coined in 1995 when the term OLE had fallen out of favor for describing components based on the COM specification). So, ADO simply refers to a data access technique, and to provide continuity with the past, the term ADO was incorporated into the new name . Originally, ADO.NET was called ADO+ just as ASP.NET was called ASP+.

Even though the name has continuity, keep in mind that the infrastructures upon which ADO and ADO.NET are built are completely different. ADO is built on the COM infrastructure, with its IUnknown interface, registry entries, reference counting, and vtable layouts, whereas ADO.NET is managed code executed by the common language runtime using the Common Type System, assemblies, XML, and garbage collection.

The continuity between ADO and ADO.NET is most clearly seen in the fact that existing OLE DB providers and ODBC drivers can be used in ADO.NET through .NET Data Providers created for that purpose. In this way, ADO.NET can also be thought of as an evolution of ADO. However, because of its deep reliance on XML, as you'll learn on Day 7, perhaps a more appropriate name might be XDO.NET (XML Data Objects).

It Combines Relational and Object-Oriented Paradigms

As you're probably aware, the substrate upon which ADO.NET is built, the .NET Framework (the common language runtime plus the base class libraries), is fully object-oriented to the core. This means that developers now have the opportunity to create OO designs using overloading, inheritance, polymorphism, and encapsulation. This in turn means that developers will want to treat and work with data in terms of objects rather than simply as a collection of columns in a row.

Although there was no mechanism, outside of hand coding, for "objectifying" data in ADO, ADO.NET supports the ability to create strongly typed DataSet s that provide a natural OO interface to data. You'll take a look at how this works on Day 6, "Building Strongly Typed DataSet Classes." In addition, we'll talk about some exciting new features to take this concept one step further on Day 21, " Futures and Wrap-Up."

It Reduces Programming Errors

Even though leveraging ADO knowledge is a good thing, many ADO programmers admit to a certain degree of confusion, especially when working with the interplay of cursor types and locations with a specific OLE DB provider. Alleviating this confusion and reducing common programming errors was another design goal of ADO.NET.

This has been done by simplifying the ways in which data can be accessed. For example, in ADO.NET there are two ways to get data: either you read an entire result set and cache it in a DataSet , or you stream through it in a read-only, forward-only manner using a DataReader object. There's no option for manipulating server-side cursors, so the issues of seeing changes made by other users, encountering deleted rows, dealing with keyset cursors, and using positioned updates all go away.

Although some readers might be alarmed by this loss of functionality, those features were the ones that caused developers the most problems and were the source of performance problems because they were often used incorrectly or inadvertently. We'll discuss ADO.NET futures and how some of this functionality might be restored in future releases on Day 21.

The root of these problems is that ADO tried to be all things to all people. By incorporating a full cursor model into the Recordset , ADO provided a unified programming model at the expense of confusion because each OLE DB provider could choose to implement the features differently or not at all. ADO.NET solves this problem by allowing each .NET Data Provider ( roughly the equivalent of an OLE DB provider) to provide its own programmatic interface to handle special functionality. A great example is the fact that the SQL Server .NET Data Provider includes a special method to execute Transact-SQL statements that return XML via the FOR XML statement. This does fracture the programming model slightly, but makes working with any particular data source simpler.

On a second level, the classes (their methods , properties, and events) in ADO.NET have been designed to eliminate the most common programming errors. For example, ASP developers often forgot to include the MoveNext object when coding a loop to display a Recordset on a page. The resulting infinite loop often caused severe problems with the Web server, which then had to be shut down manually and restarted, affecting other sites on the server. Because ADO.NET's DataReader exposes rows as a collection, they are iterated using the For Each syntax, making this sort of error impossible .

And, of course, you'll put all the features used to satisfy these design goals to use on Days 15 through 18.

for RuBoard