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.