Aggregates and Summary Rows

Chapter 7

Disconnected Web Applications

If you ve programmed data-driven applications, disconnected programming is nothing new for you. A few years ago, it was one of the most touted features of Microsoft ADO 2.x. The key difference between ADO and ADO.NET is the way in which the disconnected feature is embedded into the surrounding framework.

ADO and ADO.NET are designed differently. ADO was invented in the age of connected, 2-tier applications, and the object model design reflects that. The disconnected features of ADO were added in a nonintrusive way and exposed via the Recordset object as if they were a new, special type of cursor. ADO.NET, on the other hand, was designed at the same time XML was emerging as a hot new technology, and developers were realizing that life had a lot more to offer than the MoveNext and MovePrevious methods. The number of developers writing applications that interacted with a local, disconnected cache of data was growing. So ADO.NET is tailor-made for the .NET Framework and also designed for the new breed of application: n-tier, capable of disconnected functionality, and XML-aware.

Typically, the purpose of disconnection is to enable the application to cache data locally and then access the local cache instead of the native storage medium. However, not all applications can tolerate the latency associated with disconnection. Applications that are inherently database driven, function in a highly concurrent environment, and must work in a connected manner to detect incoming data changes just can t be adapted to work in disconnected mode. They also can t be forced to use inherently disconnected data objects. And what s the typical ADO.NET disconnected data object? You guessed it the DataSet object.