Introduction to ADO.NET - I

Introduction

The latest addition to the .NET Framework is Microsoft’s ADO.NET, an evolution of the data access architecture provided by Microsoft ActiveX Data Objects (ADO) programming model. ADO.NET is not a replacement for ADO. It has been developed with some enhancements to ADO, enabling us to create powerful and scalable web application. More importantly, it allows us to work with data in a disconnected way under the .NET Framework Stateless distributed web modal.

ADO.NET offers the following benefits:

1. ADO.NET applications can take advantage of the flexibility and broad acceptance of XML, as XML is the format for transmitting datasets across the network;
2. ADO.NET data components in Visual Studio encapsulate data access functionality in various ways that help you program more quickly and with fewer mistakes; and
3. ADO.NET accommodates scalability by encouraging programmers to conserve limited resources. Since any ADO.NET application employs disconnected access to data, it does not retain database locks or active database connections for long durations.

ADO.NET also enables truly disconnected data access. Client-Server applications have traditionally had to maintain an open connection to the database while running or provide their own method of caching data locally, which is impractical for a number of reasons, including:
  •  Open database connections take up valuable system resources. In most cases, databases can maintain only a given number of concurrent connections and the overhead of a large number of connections detracts from overall application performance. In some cases, however, a constant connection may be required and it may not be desirable or practical to close a connection;
  • Applications that require an open database connection are extremely difficult to scale up. So, an application that performs acceptably with 100 users may not do so well with 1000; and
  • F A model based on connected data can make it difficult and impractical to exchange data across application and organizational boundaries. If two components need to share the same data, both have to be connected to the same data source. Else, a reliable way of passing data back and forth between components must be implemented.

Owing to these reasons, ADO.NET was built for a disconnected architecture. Data is read into a component (an object to be precise) called a DataSet, which acts as a temporary scratch pad for data. The Dataset holds data even when the connection to the data store is broken and is good for as long as it is in scope. Data in the disconnected DataSet can be manipulated by an application before reconnecting to the data store to update it with any changes. Alterations are made in an optimistic approach. When connection is re-established for an update, original versions of the data used to populate the DataSet are compared with that currently held by the server. If someone else has modified the same information in the meantime, an error is generated and the operation rejected.

ADO.Net DataSet uses XML to transfer data. XML is a language that marks up data with customizable tags in a standard manner that allows independent organizations and applications to readily understand each other's data. XML is a text-based format, so ADO.Net can transfer data more easily and reliably through firewalls.


Comparisons to ADO

Apart from its disconnected nature, the other key advantages of ADO.NET over ADO are:

  • Whereas ADO.NET uses Datasets to hold data, ADO uses the Recordset object. An ADO Recordset represents a single table. So, even if you join multiple tables, its view will be of a single table; it is not possible to work with multiple tables at once. The ADO.NET DataSet, on the other hand, contains a collection of tables and the relationships between them, and as such is able to handle a much more complex data structure;
  • The ADO.NET DataSet provides both a table-based relational view and an XML-based hierarchical view, and either can be used interchangeably;
  • The ADO Recordset stores data in binary format, which can be a problem because firewalls tend to block binary data transfers. XML is a text-based data format, so ADO.NET can transfer data more easily and reliably through firewalls;
  • XML also permits an unlimited variety of data types and incorporates ways to validate that the correct data types are used. Since ADO uses COM as a transportation mechanism, the data and performance can be hindered by translation to and from the limited COM data types; and
  • With ADO, there was always the problem of having the correct version of MDAC to access your data, but ADO.NET supports side-by-side versions of ADO.NET without having to worry about versioning issues.

ADO.NET Architecture

The main components of ADONET (refer figure) are the .NET Data Providers and Dataset object. By separating components that manage the data (Data Providers) from those that store the data (Datasets), we allow for a loosely coupled flexible system. These components are able to work quite independently from each other. The Dataset is able to use the services of Data Providers to retrieve information. The providers make connections just long enough to retrieve data for the DataSet, and then close them.




As you can see above, we have our Dataset, which is made up of tables. There is also the .NET Data Provider that connects to the database and executes our commands.

Required Namespaces

ADO.NET is broken down into the following the namespaces in the .NET framework. Namespaces are used to organize components into groups based on organizational and logical reasons.

NameSpace

Description

System.Data

Classes located in System.Data are non provider specific i.e. non database aware classes

System.Data.SQLClient

Classes located here are managed provider for SQL Server. For SQL Server TDS protocol, this gives the best performance.

System.Data.OleDB

Classes located here are managed providers for OleDB, providing access for any OleDB provider.




Added on December 23, 2005 Comment

Comments

Post a comment

Your name:

Comment: