Monday, September 19, 2011

Windows Forms Data Binding

One of the most powerful aspects of the Windows Forms architecture is data binding.
Historically, data binding was used to bind visual views to data stored in databases and other
data sources. Some database management systems (DBMSs), such as Microsoft Access, have
provided GUI APIs to help developers quickly bind data to visual controls. Each DBMS
usually had its own associated API for data binding purposes. Some even had no associated
API, which forced developers to provide the implementation from scratch. Binding to other
types of data structures, such as arrays, was out of the question. .NET, however, solves all
these problems and more. With .NET, a client can bind to almost any data structure, including
arrays, collections, database tables, rows, and views.

Data Binding Concepts
For .NET data binding to be possible, there must be providers of data and consumers of data.
A provider of data is an object or component that exposes its data to the outside world. A
consumer is an object or component that uses the data exposed by a provider with the intent to
display or modify that data. With .NET data binding, the minimum requirement to support listbased
data binding is for the provider to implement the IList interface. The IList interface
represents an index-based collection. Data providers and data consumers are discussed in more
detail in the following sections.

Data Providers
The following objects implement the IList interface, so they are inherently data providers.

An array is simply a collection of objects that can be accessed by a numeric index. Arrays can
be either single-dimensional or multi-dimensional.

The DataSet class is a .NET representation of a database or of some other data source. It does
not, however, need to actually be connected to a real database. As a matter of fact, it acts as a
“disconnected” data source with the ability to track changes and merge new data. When
binding to a DataSet object, the data consumer is responsible for asking for the particular
DataTable or DataView object or objects with which data binding should occur. In some
cases, the data consumer would really be binding to the DataSet object’s default
DataViewManager instance.

A DataTable object typically represents a table in a database. However, it may also be used to
represent the structure of an XML element or the parent of a collection. A DataTable object
contains collections of DataColumn objects and DataRow objects. Complex controls, such as
the DataGrid control, can be bound to a DataTable object with ease. Note that when you bind
to a DataTable object, you really bind to the table’s default DataView object.

A DataView object is simply a customized view of the data in a DataTable object. For
example, it might contain all rows sorted by a particular column or all rows that match a
certain filter expression. When data binding to a DataView object, all controls involved in the
data binding process will receive a snapshot of the data at that particular moment during which
data binding occurs. Whenever the underlying data changes, the bound controls must have
some way of knowing how to refresh themselves. This process will be discussed shortly.

The DataViewManager class represents the default settings of an entire DataSet object.
Similar to the DataView class, it is a snapshot view of the DataSet object. The main difference
is that the DataViewManager class also includes relations.

A DataColumn object typically represents, and is analogous to, a column in a database table.
However, it may also represent an XML attribute or an attribute-less XML element. You can
only simple-bind to a DataColumn object. This means that only simple controls, such as a
TextBox control, can be bound to a DataColumn object.

Other .NET Objects
In actuality, any .NET object can support data binding, but you might not automatically reap
all of the benefits provided by the .NET architecture for using just any object. Also, when
binding to these objects, only the public properties (not public fields) can be bound. Therefore,
you must be careful when data binding to data sources exposed by Web services. The public
properties of any types returned by a Web service will be converted to public fields in the Web
service’s client proxy code created by Visual Studio .NET 2008.
Be careful. You can only bind to the public properties, not the public fields,
of data source objects.

Next -
Data Consumers and Binding and BindingContext

No comments :

Post a Comment