views:

153

answers:

2

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.

+1  A: 

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

  1. Multiple views on the same recordset. (ie. 2 grids with diffent sort orders/filters)
  2. Filtering,Sorting while not changing the sort order of the records themselves (Filter/Sort)
  3. 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)
  4. IErrorprovider never worked for me without a bindingsource, however this could be my fault.
Julian de Wit
I was hoping for an answer that explained the use of BindingSources as they relate to my two examples, but as it's been a week without any other answers, I'll select this as the accepted answer. Any other answers still welcome though...
Justin
A: 

This is something I'm interested in too...