The significance of two-way databinding

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/the_significance_of_twoway_databinding.htm]

ASP.Net came with one-way databinding, and seven years ago that was a big deal. Instead of looping through each element in an array and individually adding it to a dropdown, you could now just bind the array to the dropdown with a single line (or two) of code. This obviously simplified things.

this.MyDropdown.DataSource = myEmployeeList;

this.MyDropdown.DataBind();

However, there were still some complications. Because the Asp.Net CodeBehind still needed to reference the UI control (in this case "MyDropdown"), the CodeBehind still had references to the UI design. For example, if the designer wanted to change the control from a standard dropdown to a custom EmployeePicker, you'd need to update the CodeBehind. As a result, there was still a tight coupling between UI design and coding implementation. This is one-way databinding: the control loads it's data, but it has no way to save data when changed. Sure, you could abstract out styles to CSS, but that essentially just lets you set an adjective, we want to change the nouns.

 

Xaml improves this by offering two-way databinding.  Jesse Liberty has a good tutorial. By merely setting certain attributes, you can now also save any UI changes back to the data object. This allows all the data-binding to be done in the Xaml itself - the CodeBehind can be set up to have no knowledge of what UI controls it's data is being sent to, or modified by. Therefore, two-way databinding allows a true separation between code and design.

 

In the CodeBehind, set the UI control's DataContext:

this.LayoutRoot.DataContext = myObject;

Then, in the Xaml, you can specify the two-way binding on every control within that UI container. The "magic" is the "Mode=TwoWay" sub attribute.

This really clicked for me when I had the opportunity to attend a Rocky Lhotka CLSA presentation, where Rocky whipped up a simple UI form to demonstrate some backend code, and then had a talented UI-oriented coworker modify just the Xaml file (no touching Rocky's technical code). The app went from another list-details WinForm to looking like a Hollywood movie.

 

By allowing a true separation between UI design and coding, Xaml will make it easier for developers to specialize. Before, because everything was so tightly coupled, most developers had to learn both the UI technologies (HTML/JS/CSS...) and the backend technologies (C#, SQL...). Now, it's easier for developers to learn a niche in one tier. I think this is part of how the ever-expanding .Net world works - the overall application is better, and requires more knowledge to develop, but .Net is designed in such a way to spread that knowledge across more people, therefore still making it manageable to develop.