Over a million developers have joined DZone.

What Flex taught me about data-binding

DZone's Guide to

What Flex taught me about data-binding

· Web Dev Zone ·
Free Resource

Access over 20 APIs and mobile SDKs, up to 250k transactions free with no credit card required

Like most other developers, when I first came across the Flex data-binding, I thought of it as an interesting feature, but haven’t realized the true implications of it until much later. Data-binding in Flex has revolutionized the way I think about building UIs.

To understand why data-binding is so revolutionary, let’s look at standard Model-View-Controller setup for building UIs.


Let’s start off with a model. A model is simply an object which has properties for all of information we may wish to display.


package example.flextesting {
public class LoginModel {

Now, model by itself is not that interesting, as we need to add behavior. To keep separation of concerns we put all of the behavior to the controller.


package example.flextesting {
public class LoginController {
public var model:LoginModel;
public var authenticator:Function;
public function login():void {
showError = authenticator(username, password);

Boiler plate problem

Without data-binding we have to write a lot of boiler plate code which copies the data from the model to the view. In our example this may be simple as we only have three fields to copy, but in a complex forms this may be several hundred things to copy. With time, this gets so complicated that adding a new field requires us to change many things in unison: the view, the model and and code which copies it to the view.

Circular Dependency Problem

At this point we need the view to be able to lay it out in MXML. Now imagine there is no data-binding. We have a problem, we need to notify the view to update itself from the model, and we need to get the view to call the login() function in the controller. This creates a circular dependency between the controller and the view, and there is just no way around it. This means that we can not use constructor dependency-injection.

Testing Nightmare

But there is a more serious problem, we need to test our code to make sure that it works as intended. We can easily instantiate the model, but instantiating the controller requires us to also instantiate the view. In many cases it may be impractical or impossible to instantiate the view in the test, and therefore the dependency on the view from the controller is causing the problems. The reason why it may be hard to instantiate the view is that the view may have dependency on other views and other controllers.

One way to solve this circular dependency is to create an interface for the view. That way we can have two implementations of the view. One is the real view, and second is a mock implementation of the view. In the tests we can just instantiate the mock view and we are home free. While this is a good solution it requires us to write extra interfaces and extra implementations, and so it is cumbersome. Worse, any changes to the view require us to change 4 files (controller, interface, view, and mock view). Can we do better?

Data-binding reverses dependencies

Data-binding comes to the rescue. Data-binding solves our circular problem in a very clever way. It makes it so that the controller has no reference to the view. View still recognizes the controller, as the former needs to call methods on the latter when the user interacts with it, but the circular dependency is broken. Better yet, the remaining dependency is from the view to the controller, and not the other way around. This is very important, because it allows us to test the controller in isolation: we can easily instantiate the model and the controller without pulling in the view dependency.

<?xml version="1.0" encoding="utf-8"?>
<flextesting:LoginController id="cntl"/>
<mx:FormItem label="Username:">
<mx:TextInput text="{controller.model.username}"
change="cntl.model.username =
<mx:FormItem label="Password:">
<mx:TextInput text="{controller.model.password}"
change="cntl.model.password =
<mx:FormItem label="Label">
<mx:Button label="Login"
<mx:Label text="Login Failed"
color="#FF0000" fontWeight="bold"/>

The magic of data-binding comes from the curly brackets ‘{}’. As you can see in the MXML above, the TextInput and the Label are both controlled by the ‘{}’. The data-binding acts as a kind of reverse dependency, a property which is very welcome, as we are trying to isolate the controller.

What I want is reverse data-binding

Unfortunately, Flex has not taken the data-binding far enough. When the model changes, the View changes as well. But since the view is a TextField, we also want the model to change when the user changes the form. This revers data-binding is not available in Flex out of the box and so we have to simulate it by adding change events that copy the data back to the model. You can see this in the MXML above, the forward data-bindings {controller.model.username} and the reverse create a lot of extra code which clutters the application.


So what have we learned about data-binding:

  • MVC inherently suffers from circular dependencies which create problem in code, that makes unit-testing of the code very difficult.
  • Data-binding reverses the normal flow of dependencies allowing us to break up circular dependencies, and thus get a less coupled system.
  • Data-binding eliminates a lot of boiler plate code which shuttles the data from the model to the view, which makes our code easier to read and understand.


#1 for location developers in quality, price and choice, switch to HERE.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}