what is connected and disconnected architecture in asp.net.pl give me full detalis
ADO.NET's Connected Architecture
ADO.NET has been designed fundamentally to be a disconnected and distributed data access technology based on XML, so ADO is still a better approach if you need a continuous connection to the underlying database, although it does requires COM Interop. The DataReader object of ADO.NET comes closest to the RecordSet object of ADO in that it also depends upon a connection to read the data.
The DataReader Object
Sometimes an application is only required to read data and not to update or write the data. Especially if such applications need large amount of data, then it is wiser to do away with the DataSet object because of its memory overheads. The DataReader requires very little memory because it just reads the data as its name suggests. It reads only one record at a time, and for applications using huge read only data, the DataReader is an excellent alternative because it is a read only and forward only stream that cuts down significantly on memory requirements.
After creating an instance of the Command object, a DataReader can be created by calling Command.ExecuteReader to retrieve rows from a data source. Assuming a connection as in the previous example is set up, the following code illustrates how to loop through a DataReader:
Dim dReader As OleDbDataReader
Set dReader = Nothing
dReader = cmd.ExecuteReader(
Do While dReader.Read
The code above loops through the publishers table in the pubs database and displays the pub_id value for all of the publishers.
The Read method of the DataReader object is used to obtain a row from the results of the query. Columns can be accessed by passing the name or ordinal reference of the column to the DataReader. However, for best performance, the DataReader provides a series of methods that allow you to access column values in their native data types (GetDateTime, GetDouble, GetGuid, GetInt32, and so on).
for details refer...
ADO.Net introduces the concept of disconnected data architecture. In traditional data access components, you make a connection to the database system and then interact with it through SQL queries using the connection. The application stays connected to the DB system even when it is not using DB services. This commonly wastes the valuable and expensive database resource as most of the time applications only query and view the persistent data. ADO.Net solves this problem by managing a local buffer of persistent data called data set. Your application automatically connects to the database server when it needs to pass some query and then disconnects immediately after getting the result back and storing it in dataset. This design of ADO.Net is called disconnected data architecture and is very much similar to the connection less services of http over the internet. It should be noted that ADO.Net also provides the connection oriented traditional data access services.
Another important aspect of the disconnected architecture is that it maintains the local repository of data in the dataset object. The dataset object stores the tables, their relationship and different constraints. The user performs operations like update, insert, delete to this dataset locally and finally the changed dataset is stored in actual database as a batch when needed. This greatly reduces the network traffic and results in the better performance.
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.