Data Binding Part 1- The Basic Idea

If you are or have ever been part of the Microsoft development community, you probably have heard a lot of talk about data binding.  “Data binding is the best”, “I don't know what I would do without data binding”, you know, that sort of thing.  But for people that are new to the platform, you might have not have a true understanding of what data binding is and how to take advantage of it.  You might be familiar with the term and even know the basic concept, but maybe you haven't really taken the time to understand it’s intricacies.  Well, being relatively new to data binding myself, I figured I would take the time to create a series of posts on data binding that will start from the most basic concepts and work our way up through hands on code samples.  This way, regardless of which person you are, one that has never heard of data binding or one that just wants to learn more about it, I should have you covered.

So, what exactly is data binding?  According to MSDN.com, “Data binding is the process that establishes a connection between the application UI and business logic.”  Just for reference, Wikipedia has the same quote, so at least we know we are starting with a solid and universally accepted definition :)  Anyways, that seems simple enough, but what does the “connection” referenced there actually entail?  Well, first off, let’s briefly define the two different parties involved in the connection, the application UI and the business logic.  The application UI is pretty simple, basically the layout and look of the app, the User Interface, but what about the business logic?  What we really are talking about here is the data that we want to be displayed on the UI and how best to show and manage that data.

Let’s take a very simple example where we have a UI that displays three different texts regarding a movie, one for the title, one for the rating, and one for the year.  If we always want to display the same movie, we can just set the Text property of each of the Textblocks to hardcoded strings in the XAML.  Keep in mind that by doing so, we limit ourselves to only using those three strings unless we manually and dynamically change the text property in the code behind. 

Now let’s consider a more realistic approach where we want to display those same three things, but for any given movie.  We don't necessarily know which movie we are going to display, we just know how we want it to be displayed.  The basic concept of data binding comes into play here.  Data binding allows you to set, for example, the Text property of a TextBlock to a piece of information without really knowing what that information is before hand.  You just tell that Text property to “bind” to a certain piece of data.  In other words, data binding provides that connection between the Textblock (UI) and the data (business logic), allowing the developer to treat them completely separately and independent of one another.  This is the true power of data binding represented in a very simple example as it ads a greater level of organization and testability to our apps.

Now that we have the general concept, let me more formally define a couple of terms.

binding target object- the UI control to bind the data to (ex. Textblock)

target property- the property of the binding target object to bind (ex. Text property of Textblock)

binding source- the data object to bind to the UI

path to value- path to the property of the binding source data object

Going back to our movie analogy, let’s say that we have a simple movie class/object that has three different text properties as above, Title, Rating, and Year.  So, a more concrete example would be the following.  If you want to bind the content of a TextBlock to the Title property of a Movie object, your target object is the TextBlock, the target property is the Text property, the value to use is Title, and the source object is the Movie object.  This gives us a more specific example, but we still have yet to see what this actually looks like in code.  Don't fear, I will cover that example hands on in code in the next post!

Before we finish this post, i want to mention one last thing.  As a developer you have the option to configure each data binding in one of four different ways.  Either changes to your data can propagate changes to the UI or changes to the UI could propagate changes to the data or both.  In addition, you can have a OneTime binding that only does the initial binding and no subsequent changes will be propagated in either direction.  Here are simple definitions for those four options.

One Way- causes changes to the source property to automatically update the target property, but changes to the target property are not propagated back to the source property

Two Way- causes changes to either the source property or the target property to automatically update the other

OneWayToSource-is the reverse of One Way binding; it updates the source property when the target property changes

OneTime- causes the source property to initialize the target property, but subsequent changes do not propagate

So, in a very theoretical approach that is what data binding is.  The key to remember is that it allows developers to work with the UI and business logic independent of each other.  Keep this in mind as we will be moving to a hands on sample in code in Part 2

As always comment with any questions, comments, or concerns below!

Comments

• Anonymous
  June 08, 2014
  Hi All Just curious with the rapid move to SPA's and various JavaScript libraries is data-binding really relevant anymore?? Also with the cloud -- efficient data strategy make some of these options bad design. Regards