becoming extremely fat. Originally operating as a simple way to interact with a SQL result set, the RecordSet object had grown to support disconnected sets of data, data shaping of multiple datasources, and a complex SQL generation layer that could support optimistic locking. In short, the RecordSet object was the universal data access object for COMoriented environments.

As Internet applications evolved, it became clear that their true strength would be their ability to operate as loosely coupled systems. These systems can easily communicate and exchange data across a heterogeneous environment and through an infrastructure whose primary common transmission protocol was HTTP. ADO depends heavily on COM and specifically on Advanced Data Table Gram (ADTG) as the native transmission format, which requires conversion of this binary format to derivative forms such as XML in order to support robust transmission across HTTP. ADO.NET provides the needed evolution by natively supporting XML, a text-based format, as the transmission format. This evolution provides the ability to access middle-tier business logic on any platform or standard — CORBA, COM, and so on — supporting XML, and have the services of these middle-tier applications made available to one another through the serialization and deserialization of XML for data interchange. When the transmission occurs through an XML-based standard there is a significant reduction in the amount of effort and data conversion required to access data in a heterogeneous environment.

Today’s Internet application systems need to be highly scalable and redundant. As systems scale, one of the primary limitations becomes the ability of the relational database management system (RDBMS) to maintain and support open connections to the middle-tier business objects. Typically there is a fixed limit to the number of open connections that can be supported by the RDBMS. In a distributed environment, it is likely that you will have a higher number of middle-tier components desiring simultaneous connections to the data store. To the extent that these components require an open connection for sorting, filtering, and manipulating the data, scalability is tremendously limited. ADO.NET natively supports a disconnected approach that involves pulling down the core set of data and then performing all filters, sorts, and manipulations on the middle tier. Because of its XML-based nature, it can also transmit the manipulated data set to another component for further processing before finally submitting it back to the original data store for update. In the ADO model, the extent of the disconnected manipulation was limited and thus impacted scalability — you had to programmatically handle connection opens and closes. In ADO.NET these happen automatically.

Differences between ADO and ADO.NET

The previous section discussed at a high level some of the fundamental changes in the ADO.NET framework that are driven by a move to highly distributed, loosely coupled, and thinly connected applications. This section provides a more detailed look at the differences between ADO and ADO.NET.

Transmission formats

ADO utilized a very efficient and compact binary format, the Advanced Data Table Gram (ADTG) format, to provide transmission of data between applications. This limited the direct transmission of a set of data to applications that could support this format, in this case COM applications. The transmission of data was further limited in the world of the Internet as

there was not an easy method for sending this binary format efficiently across firewalls that often only supported HTTP. These factors effectively limit the full functional use of ADO to COM environments.

ADO.NET, by contrast, natively supports the text-based XML format for transmission of data. As a text-based, open, and widely accepted standard, XML can and is supported in COM, CORBA, and numerous other computing environments. As a text-based format, it can be readily communicated across HTTP, providing a simple method to transmit structured data across corporate firewalls.

Connected versus disconnected datasets

ADO (ActiveX Data Objects) is an application programming interface (API) for accessing data primarily in a connected (cursor-based) scenario. ADO provides the capability of using a connection-oriented approach to creating, updating, and deleting data through pessimistic locking. This is a preferred approach in a twoand three-tier environment. ADO optionally enables you to operate with a client-side cursor providing a disconnected method as well, and thus provides a solution for n-tier development.

ADO.NET is an API to access data and information in a disconnected manner. It is thus not very useful in a client/server environment, and in fact is optimized for use in a n-tier environment in which maintaining open connections to the datasource are typically inefficient and ineffective.

COM marshaling versus text-based data transmission

When operating in a purely COM environment it is clear that the ADO model provides a very rich and attractive programming interface. Its ability to use multiple cursor types and connections, and to easily shape, sort, filter, and modify data on multiple-relational and nonrelational sources is apparent. However, the ADO model is only an advantage if all systems that are interacting with each other are COM based. These very same benefits are a liability in a distributed and heterogeneous environment where mainframe, UNIX, and numerous other non-windows-based platforms are involved. In the ADO world, the transmission of a disconnected recordset from one component to another involves COM marshaling and forces the receiving component to support COM to accept the transmission. Therefore only COM objects can use ADO recordsets. And while ADO did provide the capability to save content to XML and rebuild from an external XML file, the default XML schema employed was optimized for use in an ADO environment (as opposed to transmission to non-COM based systems). With ADO.NET, the native support of XML overcomes these issues and provides an approach for transmission of almost any data type between almost any type of platform. This allows mainframe systems to communicate with COM-based middleware and then have the result modified by a CORBA-based Java Servlet while having the data roundtrip back and updating a centralized relational or nonrelational datasource.

Variant versus strongly typed data

ADO by default will utilize variant data types to comply with script-based environments. This means that the data types will not be evaluated until runtime, and that they must be evaluated prior to committing them back to the originating datasource in most cases.