What is data binding?

A good example of this is a list box that shows several items. If you’re writing a list box that can only show an alphabetical list of country names, it won’t be very useful in other applications. It would be really bad if anytime we wanted to use a list box, we had to write it all over again for each scenario.

List boxes normally have methods you can call to add and remove items displayed. That’s not data binding though. A list box capable of data binding will have a property such as dataSource. All you have to do is point the list box to the source of the data and it can go get the items to be displayed itself. This really helps simplify your code. All you have to do is change sources and you get new data.

But if there’s a bigger benefit, it has to be that the link between the consumer of the data and the source of the data can remain even though the data itself changes.
Have you ever used an application that presents a list of items and allows you to select one and get more information about it? Sure you have. Even this podcast is a list of episodes and once you select an episode, you can see details about the episode and play it.

This is called a master-details pattern. You need a data source of all the items and you start out by setting the data source for your list control to this source. But you also need to tell it what properties to use. Maybe the data source has many different collections of items. You need to let the list box know which property on the source has the data it needs to display. You can get as specific as you need and you might also need to tell the list box which property to use as a unique identifier and which property to use for the display text. Users don’t normally care about identifiers. They just want a friendly name for things.

Then your list control can update its own property that it uses to let other code know which item is currently selected. That enables the other benefit of a well designed data binding system to allow just the data to change while the source remains unchanged. A data source can let other code know when properties change. Listen to episode 77 about the observer design pattern for more information.

We need a data source for the details view and while this could be the list control, it would be better to introduce another object that’s focused on just a single item at a time and that binds to the currently selected item in the list control. This object will use the currently selected identifier to fill in various details about the selected item and will act as a controller for the details view. When the user selected a new item, the source of the currently selected item remains the same and only the data that identifies which item is selected needs to change. That’s the data that the new controller object will be watching out for.

Then you can have a whole page of views that each bind to one or more of the detailed properties. If this is a list of podcast episodes, then maybe one of them is the name and another is the length. You may or may not want to show the name again. That’s up to designers and usability tests to find out what customers need and expect. But something like the length of the episode probably won’t appear in the main list of episodes. I mean, it could, but in general, you don’t want to put all the information into a big list control. You just want to put enough information so the user can find what they’re looking for and then display all the other details in the details view. The details view will then have a bunch of controls, edit boxes, numeric controls, check boxes, etc. that all work together to show the details for whichever item is selected in the master list control. Each of these controls will bind to the controller object that exists to focus on just one item at a time. That’s why this pattern is called master-details.

Listen to the episode for additional benefits to using data binding.


What's on your mind?

On a scale of 0 to 10, how likely are you to refer us to a friend?