Application Security Testing: An Integral Part of DevOps
ADO.NET, the data-access component of the Microsoft.NET Framework, works with any component on any platform that understands XML, which is a standard format for transmitting data. ADO.NET exposes a simple object model that conforms to the standards prescribed by the World Wide Consortium (W3C). It is an evolution of the ADO data access model that directly addresses user requirements for developing scalable applications.
ADO .NET was designed specifically for the Web with scalability, statelessness, and XML in mind. The ADO.NET interface is readily accessible using any of the .NET-compliant languages.
ADO.NET is essentially a collection of classes that expose methods and attributes used to manage communications between an application and a data store. An integral part of the .NET Framework, ADO.NET simplifies a variety of development needs, including the creation of front-end database clients and middle-tier business objects used in distributed, data-intensive applications.
ADO.NET is not just another object model for working with data. In essence, it is ADO revisited on a wider-range, cross-platform scenario. ADO.NET is ADO extended to work in cooperation with any software component, on any platform, that understands XML.
ADO .NET supports a rich disconnected view of data as represented by data sets, cursors, batching, data shaping, connection pooling, meta data access, and a host of other techniques that will allow you to build performance, reliability, and robustness in your data applications.
Evolution of ADO.NET from ADO
Under the .NET Framework, data access is handled by a set of classes called ADO.NET; these are essentially an augmentation of the existing ActiveX Data Objects (ADO). There are some big changes, both internally and on the surface. The most obvious internal change is that ADO.NET is based entirely on XML. Externally, the biggest change is that there is no Recordset object.
The Recordset mechanism was used to interact with the results of an SQL Query; later, it grew into a structure that supports disconnected or even fabricated recordsets. The challenge it faced was the 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, which are explained below:
- The DataReader object allows you to perform a single pass through a set of records as efficiently as possible whereas 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 whereas 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.
- Updation of data through pessimistic locking is not supported in ADO.NET. It is targeted at n-tier, Web-friendly applications and it does not intend to tread on ADO's toes in all areas. In ADO, updating data is done through connection-oriented pessimistic locking.
The other major differences between ADO and ADO .NET are as follows:
- XML in ADO.NET allows data to pass through a firewall. Data cannot pass through a firewall through the ADO recordset.
- ADO.NET supports the typed dataset, which means they support all the dataset capabilities built into .NET, including binding and XML DOM interoperation. In ADO, recordset fields are not strongly typed and are not supported by IntelliSense.
- ADO.NET DataSet can hold multiple tables and therefore is very flexible. In ADO, a recordset holds data only for one table.