DataTables and a Binding Source

Question

I am trying to understand the difference between the following 2 examples.

First, this is how I currently assign Data to a control in my WinForm App.

            lkuCounty.Properties.DataSource = Person.CountyList();
        lkuCounty.Properties.PopulateColumns();
        lkuCounty.Properties.DisplayMember = "CountyName";
        lkuCounty.Properties.ValueMember = "CountyID";
        lkuCounty.Properties.Columns[0].Visible = false;
        lkuCounty.Properties.Columns[2].Visible = false;
        lkuCounty.Properties.Columns[3].Visible = false;

This seems to work though I'll admit that if it is slightly off I probably lack the experience to tell just by looking at the code. Also of note, Person.CountyList() actually returns a DataTable :\

Now how all of the examples I find seem to say I should do this.

memberBindingSource.DataSource = Person.CountyList();
        lkuCounty.Properties.DataSource = memberBindingSource;
        lkuCounty.Properties.PopulateColumns();
        lkuCounty.Properties.DisplayMember = "CountyName";
        lkuCounty.Properties.ValueMember = "CountyID";
        lkuCounty.Properties.Columns[0].Visible = false;
        lkuCounty.Properties.Columns[2].Visible = false;
        lkuCounty.Properties.Columns[3].Visible = false;

Is there a benefit to using the BindingSource? Is there a negative to doing it the OTHER WAY?

For context, this is a WinForm CRUD app in C# using SQL 2005.

Answer 1

For standard DataSets/DataTables, the BindingSource merely provides another layer of indirection between your controls and the actual data source.

However, most data-aware controls can only be bound to certain data sources (those implementing IList, IListSource, IBindingList or IBindingListView). This presents a problem if you need to use a custom object as a data source, because said object then needs to implement at least one of those interfaces.

So you can either implement the entire IList interface in your business object - or you could inherit your object from the List class and bind it up to a BindingSource, which you then bind to your Control(s).

The long and the short: unless you're certain your data sources will always be DataTables and the like, use a BindingSource. It does add a slight performance overhead, but it can make your life a lot easier.

There is also some very nice state-management functionality built into the BindingSource, which comes in very handy if your application is stateful. Instead of you writing custom state-handling code, just let the BindingSource handle things for you!

Answer 2

You can bind directly to any object, as in the first example. However, that object will need to implement many of the data binding interfaces for it to respond intelligently to the events fired by the control.

For example, bind a List of Person to a DataGridView. Now, click a column header to sort a column. It does not work because List does not implement the needed interface. Try the same thing with a DataTable. The column sorting magically works. That's because DataTable implements all the needed interfaces for Data Binding.

    public class Person
    {
        public string Name { get; set; }
        public int Age { get; set; }

    }
    private void Form1_Load(object sender, EventArgs e)
    {
        //does not sort...
        dataGridView1.DataSource = new List<Person>
        { 
            new Person{ Age=11, Name="Jimmy" },
            new Person{ Age=12, Name="Suzie" }
        };
    }

You can write your own classes that implement the data binding interfaces. It's alot of work. Here's a great book on the subject:

Data Binding with Windows Forms 2.0: Programming Smart Client Data Applications with .NET