Connected and disconnected scenarios

In ADO.NET, there are two main scenarios for working with data: connected and disconnected scenarios.

In the connected scenario, the application maintains an open connection to the database throughout its lifetime. This approach is suitable for applications that require continuous access to the database, such as applications that display real-time data or perform continuous data processing. The connected scenario involves the use of classes such as SqlConnection, SqlCommand, SqlDataReader, etc. to interact with the database.

In the disconnected scenario, the application connects to the database, retrieves the required data into a dataset, and then closes the connection. The application then works with the data in the dataset, and any changes made to the data are later persisted back to the database. This approach is suitable for applications that require periodic access to the database or that operate on subsets of data. The disconnected scenario involves the use of classes such as SqlDataAdapter, DataSet, and DataView to interact with the data.

Data binding is the process of connecting a user interface control to a data source, such as a database, and automatically displaying and updating the data in the control. In a Windows Forms application, data binding can be achieved by dragging and dropping a control, such as a DataGridView, onto a form and configuring its data source. Alternatively, data binding can be done programmatically using classes such as BindingSource, BindingList, and BindingManagerBase.

In summary, the choice between the connected and disconnected scenarios in ADO.NET depends on the requirements of the application. Connected scenarios are suitable for continuous access to data, while disconnected scenarios are suitable for periodic access or working with subsets of data. Data binding provides a convenient way to display and update data in a user interface control, either through visual design or programmatically. 

Comments

Popular posts from this blog

OpenSolaris and Linux virtual memory and address space structures

Tying top-down and bottom-up object and memory page lookups with the actual x86 page translation and segmentation

OpenSolaris and UNIX System V system administration pragmatics: service startup, dependencies, management, system updates