ADO.NET - A Natural Evolution
In the beginning, there was Microsoft ActiveX Data Objects (ADO). Okay, that was a long way from the beginning, but ADO has been around a few years-a lifetime in Internet terms. As with all things, ADO came to us through a normal evolutionary process, based on Data Access Objects (DAO) and Remote Data Objects (RDO). Following in this evolutionary model, Microsoft created ADO.NET.
If you have experience with ADO, you know that the RecordSet was the centerpiece of the model...where the rubber met the road, so to speak. In ADO.NET, the DataSet is the centerpiece. It's an in-memory copy of the data from a data store. Unlike an ADO RecordSet, a DataSet can contain any number of DataTables, each of which could represent the data from a database table or view. The DataSet resides in memory, disconnected from the original data store. In other words, the DataSet can exist without an active connection to the data store.
The underlying technology at work is XML (Extensible Markup Language), which is the persistence and transmission format for the DataSet. At runtime, components (such as a business logic object or an ASP.NET Web Form) need to exchange the data in the DataSet. The data is transmitted from one component to the other in the form of an XML file, and the receiving component materializes the file in the form of a DataSet. The DataSet is built with methods consistent with the relational data model. As mentioned earlier, the DataSet has a collection of DataTables. Each DataTable has a collection of DataRows and DataColumns, as well as relationships to other DataTables.
With evolution come new, and often great things. Such is the case with the evolution of ADO into ADO.NET. The prime benefits can be broken down into five categories: Interoperability, Maintainability, Programmability, Performance, and Scalability.
ADO.NET is designed to take advantage of the acceptance of XML. Because the work being done under the covers is in XML, any component that can parse XML can use ADO.NET.
As a Web application grows in popularity architectural changes may be required to handle the increased traffic. This is often handled by dividing an application into a multi-tiered architecture. Using ADO.NET eases the pain of having to make a substantial architectural change. This is because ADO.NET is using disconnected XML files as its transmission format. Components in multiple logical or physical tiers can still exchange data easily.
Programmers can work with ADO.NET objects through strong-typed programming. This enables easier to read code and debug code. With strong-typed programming, objects important to the user become important to the programmer. In conventional, not strong-typed programming, you might write:
Name = Table["User"].Columns["Name"];
Using strong-typed programming, the table and column are objects that can be accessed directly.
Name = User.Name;
In the past, when data was passed from one component to another, the application's performance took a heavy hit due to the cost of COM marshalling. In ADO.NET, this data type conversion is not required because you are simply passing an XML file.
The single largest impediment to scalability is contention for a limited set of resource. This contention is manifested in database locks and connections. Since ADO.NET relies on disconnected XML files, these high-demand resources are freed up, improving scalability.