ADO.NET's Disconnected Architecture
We have been continuously stressing that ADO.NET uses a disconnected
architecture. With the ever-increasing demand on the Web, data requirements are changing. Now, scalability has become a major issue thanks to the ever growing population of the web. Another aspect is availability of an open connection for the data all of the time. Both these issues require that applications should connect to the data source, read required data and disconnect the connection, process the data, reconnect and save the changes. Using disconnected RecordSets is tedious with ADO due to marshalling issues. All this was leading to disconnected architecture for quite some time now.
It was but natural that Microsoft would introduce this architecture in the latest version of ADO, which is ADO.NET. We have just seen how to use a Connection object, a Command object and a DataReader to perform database operations. This is good enough when you want to process only one row at a time. In practice however, one needs to process or display multiple rows at a time. In such cases, it is difficult to use the DataReader. Therefore, ADO.NET provides other objects for such operations. These objects are mostly use in a disconnected environment.
The DataAdapter Object
Data adapters are an integral part of the ADO.NET managed providers. They are the set of objects used to communicate between a data source and a DataSet. Adapters are used to exchange data between a data source and a DataSet. Mostly, this would mean reading data from a database into a DataSet, and then writing changed data from the DataSet back to the database. The DataAdapter, however, is more capable. It can move data between any source and a DataSet. For example, there could be an adapter that moves data between a Microsoft Exchange server and a DataSet.
Generally, we can configure the DataAdapter so that we can specify what data to move into and out of the DataSet. Often this takes the form of references to SQL statements or stored procedures that are invoked to read or write to a database. ADO.NET has two primary data adapters for use with databases:
The OleDbDataAdapter: This object is suitable for use with any data source exposed by an OLEDB provider.
The SqlDataAdapter: The SQLDataAdapter object is specific to SQL Server. Because it does not have to go through an OLEDB layer, it is faster than the OleDbDataAdapter. However, it can only be used with SQL Server 7.0 or later.
This means that vendors can create vendor specific DataAdapters that can be faster or more efficient for different types of data sources. Normally, one DataAdapter is created for one table or data set. If the DataSet consists of more than one table, usually a separate DataAdapter is created for each table. For populating a DataSet, a DataAdapter's Fill method is called. For writing the updated data back to the table, the DataAdapter's update method is called. A DataAdapter is created by the DataAdapter configuration wizard or by using the server explorer. A DataAdapter can also be configured manually by using the property window.
The DataSet Object
The DataSet object can be thought of as the heart of ADO.NET's disconnected architecture. The DataSet object is an in memory copy of the data stored by a DataAdapter. The structure of the DataSet is like a relational database. It exposes a hierarchical model of tables, rows and columns. It also contains constraints and relations just like a database. When working with a set of related tables, the DataSet becomes a handy object.
Another important feature of the DataSet is that it uses XML to represent the data.
The structure of the DataSet, its tables, rows, columns, and everything else can be defined as an XML schema. A DataSet can read and write XML schemas using its ReadXmlSchema and WriteXmlSchema methods. XML is used to store and transmit data of all kinds. As XML is an almost universally accepted format, the data can be transported to or received from any platform using a DataSet.
The DataSet is populated with:
A DataAdapter's Fill method
Using the ReadXml method
The DataSet is not connected to a data source after it is populated. This feature differentiates it from ADO objects. An ADO RecordSet has record pointers while all the records are current in a DataSet. That's why it does not support record navigation methods. Instead of using a record, the DataSet object uses the Rows collection. It can still be manipulated like any collection, however. AS the DataSet is an in-memory database, ADO.NET provides us with methods to build the schema for the DataSet easily.
Please rate this post, if it is useful for you.
Thanks & Regards