I think I understand well enough what the BindingSource class does - i.e. provide a layer of indirection between a data source and a UI control. It implements the IBindingList interface and therefore also provides support for sorting. And I've used it frequently enough, without too many problems. But I'm wondering if I use it more often than I should. Perhaps an example would help.
Let's say I have just a simple textbox on a form (using WinForms), and I'd like to bind that textbox to a simple property inside a class that returns a string. Is it worth using a BindingSource in this situation?
Now let's say I have a grid on my form, and I'd like to bind it to a DataTable. Should I use a BindingSource now?
In the latter case, I probably would not use a BindingSource, as a DataTable, from what I can gather, provides the same functionality that the BindingSource itself would. The DataTable will fire the the right events when a row is added, deleted, etc so that the grid will automatically update.
But in the first case with the textbox being bound to a string, I would probably have the class that contains the string property implement INotifyPropertyChanged, so that it could fire the PropertyChanged event when the string changes. I would use a BindingSource so that it could listen to these PropertyChanged events so that it could update the textbox automatically when the string changes.
How does this sound so far? I still feel like there's a gap in my understanding that's preventing me from seeing the whole picture. This has been a pretty vague question so far, so I'll try to ask some more specific questions - ideally the answers will reference the above examples or something similar...
(1) Is it worth using a BindingSource in either of the above examples?
(2) It seems that developers just "assume" that the DataTable class will do the right thing, in firing PropertyChanged events at the right time. How does one know if a data source is capable of doing this? Is there a particular interface that a data source should implement in order for developers to be able to assume this behaviour?
(3) Does it matter what Control is being bound to, when considering whether or not to use a BindingSource? Or is it only the data source that should affect the decision? Perhaps the answer is (and this would seem logical enough): the Control needs to be intelligent enough to listen to the PropertyChanged events, otherwise a BindingSource is required. So how does one tell if the Control is capable of doing this? Again, is there a particular interface that developers can look for that the Control must implement?
It is this confusion that has, in the past, led to me always using a BindingSource. But I'd like to understand better exactly when to use one, so that I do so only when necessary.
Hi I also have some confusion about the subject.
When I use datatables those implement all the interfaces.
However I always use the bindingsource just to be sure.. :)
There are some arguments why that I can think of
- Multiple views on the same recordset. (ie. 2 grids with diffent sort orders/filters)
- Filtering,Sorting while not changing the sort order of the records themselves (Filter/Sort)
- Ability to disable binding for a while for performance reasons. (when there are big updates in the table, don'y listen to all the IXXChanged events)
- IErrorprovider never worked for me without a bindingsource, however this could be my fault.
Pretty old question. Wonder why anyone hasn't answered it till now. OK, I'll try and share things from my experience.
A BindingSource is more than just a way to bind controls to collections. After having worked in WinForms for over a decade, the best features of a BindingSource that I like the most include:
- Binding (of course!)
- Currency management (I'll come to that in a second)
- A
BindingSource can act as a data source of another BindingSource.
To fully appreciate these features, I'll explain them in the context of a DataSet, which is by far the most common type of data source used in WinForms, especially in line-of-business apps.
Currency management boils down the concept of current record. A DataTable is just a collection of DataRows, i.e. there is no concept of current record in DataTables. Same is the case of DataView (on a side note, you cannot directly bind to a DataTable; when you do that, it actually binds to the DefaultView property of that DataTable, which is a DataView. You could create your own DataView too).
Currency management really proves handy in case of Master/Detail kind of UI. So let's say you have a ListBox of Students in the left pane (Master), and several TextBoxes, ComboBoxes, CheckBoxes etc. in the right pane, with a grid of selected student's courses (Detail). In your DataSet, you have two DataTables named Student and Courses. For the sake of simplicity, I'm avoiding a gerund (Student_Course) here. The Course table has a foreign key StudentID. Here's how you setup binding here (note how all the 3 features I listed above are used in the setup below):
- Add two
BindingSource controls to your form, named bsStudent and bsCourses.
- Set
DataSource of bsStudent to Student DataTable.
- Set
DataSource of bsCourses to bsStudent!
- In the
DataMember property, you'll see the name of the relation that exists in the DataSet between our two tables. Select it!
- Set the binding of individual atomic controls to
bsStudent's properties.
- Set the
DataSource of courses grid bsCourses.
And you're done. Without writing a single line of code (so to speak), you have successfully created a master-details view. The BindingSource control will now take care of the current record in Students list and update not only the atomic controls (TextBoxes, ComboBoxes etc.), but also the courses grid, which will automatically update its contents to show the courses of currently selected student.
This, my friend, is the role of BindingSource (among other nice things like sorting, filtering etc.) which I like the most. Without involving a BindingSource in-between your controls and the data store, you'd not have the concept of current record and therefore would manually have to manage keeping all the UI in sync.
I also would like to add, using BindingSource, you can bind to a business object, which can implement INotifyPropertyChanged event, so if data is changed (whether by your code or someone else's code), your UI can automatically reflect the updates.
