This article gives a nice introduction to the .NET is data access ADO.Net. If you have been keeping up to date with developments in ADO, then ADO.Net will come as less of a shock than you might think. All the same, there are some big changes, both internally and on the surface.
Among the many things that are changing with .NET is data access. Under the .NET Framework, data access is handled by a set of classes called ADO.Net, which are essentially an augmentation of the existing ActiveX Data Objects (ADO). If you have been keeping up to date with developments in ADO, then ADO.Net will come as less of a shock than you might think. All the same, there are some big changes, both internally and on the surface. The most obvious internal change is that ADO.Net is entirely based on XML. Externally, the biggest surprise is that there is no Recordset object.
You may be thinking that there can't be much in common between ADO.Net and ADO if there's no Recordset object. However, Microsoft's view is that the Recordset was becoming rather bloated. What started as a mechanism for interacting with the results of an SQL query has grown into a structure that supports disconnected or even fabricated Recordsets; can contain multiple child Recordsets organized into a hierarchy through data shaping; and includes a sophisticated SQL generation layer capable of simulating optimistic locks without needing to hold physical locks that otherwise restrict scalability.
Under ADO.Net, the functionality of the Recordset has been split into three groups.
The DataReader object allows you to perform a single pass through a set of records as efficiently as possible. In ADO, this was achieved using a forward-only, server-side cursor. The DataSet and DataSetCommand objects allow you to create a client-side cache of one or more related Recordsets and process it in a disconnected fashion. In ADO, a client-side cursor was used for much the same thing. By separating out these two very different sets of functionality, ADO.Net can provide tailored support for each approach, as well as exposing more power.
The third area of functionality is everything else that ADO can do. This includes, for example, using a connection-oriented approach to updating data through pessimistic locking. You can't do this in ADO.Net (at least not as it stands) which means you will certainly continue to use classic ADO for some time yet. ADO.Net is firmly targeted at n-tier web-friendly applications: it doesn't intend to tread on ADO's toes in all areas.
So, before going into the details of DataSets and the relationship between ADO.Net and XML, let's take a look at ADO.Net in action.
User ReviewsTotal of 1 review
ExcellentWritten by Rajesh K on August 28, 2002