A number of things come into play to make data binding happen. First, you need the data. From the perspective of a presentation layer client application, this comes in the form of in-memory data sources. You need controls or components that are designed to work with that data to automatically present it and push changes back to the data source. This functionality may be encapsulated in the top-level controls that the user sees on the screen, reside in some intermediary component the acts as a middleman between a control type and a data type, or involve a combination of both the control and an intermediary component. If you will have multiple controls on a form that are all bound to the same data source and want those controls to behave as a unit, staying synchronized with changes to the underlying data source, you're going to need some support from the container of those controls to keep them all in sync. These mechanisms are all present in Windows Forms data binding.

You can use a variety of data sources to accomplish data binding in Windows Forms, such as data sets, custom collections, or individual business objects. You can bind those data sources directly to Windows Forms controls that are part of the .NET Framework, purchase third-party control libraries that support data binding, or write your own data-bound controls. Windows Forms 2.0 introduces a BindingSource component that lets you code complex data-binding scenarios with a lot lessand more maintainablecode. And the Form class itself also has built-in support to manage the synchronization of multiple controls on a form that are all bound to a single data source.