ADO.NET - A Natural Evolution
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.
Interoperability
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.
Maintainability
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.
Programmability
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;
Performance
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.
Scalability
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.