Modifying a DataBound Collection - Page 8
       by kirupa  |  9 December 2007

In the previous page, we finished up (most) of our explanation on why the code we added works by looking at each line. In this page, we'll wrap up the code explanation and take a look back at what the past seven pages were about!

Let's look at the final piece of code that hasn't been explained yet:

private void WindowInitialized(object sender, EventArgs e)

{

PeopleData.PeopleDataSource = this.FindResource("PeopleListDS") as ObjectDataProvider;

}

In our Window1.xaml.cs file, you have your WindowInitialized event handler. If you recall, this was created via Blend when you setup this event handler for your Window's Initialized event.

You only do one thing in this event handler. The one thing you do is initialize your PeopleDataSource static method found in your PeopleData class with the data provider already defined for you in XAML

Most of this should be review, but do you know why you even have this code in the WindowInitialized event handler? You have this code because, if we wanted to add new people to our listbox, you need to use the PeopleDataSource static property declared in your PeopleData class. That means your PeopleDataSource property needs to be initialized to the data provider that already exists.

If you tried to add a person before the PeopleDataSource property had a value, your application will throw an exception and crash your application. The only way to ensure that this does not happen is to initialize PeopleDataSource immediately after your Window has been initialized. To look at this another way, before you quickly get a chance to do anything, you want to make sure that PeopleDataSource has been initialized.

You may be wondering why go through all of this hassle? Why not just check if PeopleDataSource is initialized prior to the Add button click? After all, that is what we did in our initial implementation of our solution. The problem, beyond complicating our AddButton_Click event handler with unnecessary things, limits the checking to only when a button is clicked.

You may have scenarios where you are adding people to your list from an external data source where the Add button is never even used. You could duplicate the PeopleDataSource initialization check, but that makes your code less maintainable because you now have more than one area that you need to maintain consistency between.

Quick Review
Amidst all of the coding in the past few pages, the reason why this article exists may have gotten lost. The problem was, you had an application where you have some data that has already been databound to a control. For example, in our case, the sample project used Blend to data bind our ListBox's ItemsSource property to a collection of people.

Any initial people in our collection were automatically being displayed, but we wanted to add more people using our textbox and Add button. We accomplish that by hooking into the existing data binding relationship that already exists and is defined in the XAML. Once you hook into the existing data source, which is a custom type called PeopleList, you can add/remove/modify elements like you would for any other collections-based type.

The only hurdle was figuring out how to gain access to the existing data provider. The rest was simple. What was less simple was taking an "ok" solution and making it into a "better" solution. The past few pages dealt with increasing the abstraction between the UI and the actual data. While I already provided some advantages of that, let's look at how this makes life for you or a future coder of this application easier.

One of your goals when writing applications should be to make sure that, several years down the road when you are revisiting this application, you can quickly understand what is going on as well as quickly being able to add or remove functionality. Beyond just for your benefit, if others were to take a look at your code, they too should find it easy to become familiar with what you wrote.

By placing important pieces of functionality into logical groups helps immensely with that. We created a PeopleData class that handles all things related to people and their data. Initially, much of that information was in our Add button's event handler, but as you can see, it does not make much sense to use an event handler to do boring data work. And with that, this tutorial is over!

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8