This post is to present a new approach of implementing ASP.NET GUI by incorporating databinding (DBN) instead of the traditional data assignment (DA) approach.

Traditional Approach

Traditionally, assigning a value to a server control involves a code-behind assignment, for example, assigning a label with a person’s birthday would have code similar to the following:

<!--ASPX-->
<asp:Label id="lblBirthdayDate" />
//C#
lblBirthdayDate.Text = person.Birthday.ToLongDateString();

If somewhere in the page the birthday should also be displayed as short date, developer would then have to create another label, and assign it:

<!--ASPX-->
<asp:Label id="lblBirthdayDate" />
...
<asp:Label id="lblAnotherBirthdayDate" />
//C#
lblBirthdayDate.Text = person.Birthday.ToLongDateString();
lblAnotherBirthdayDate.Text = person.Birthday.ToShortDateString();

Let’s say later, customer would like to see birthday information displayed different, such as removing one label or another, developer would have to remove the label from the ASPX markup as well as the code behind, recompile the DLL and deploy both the DLL and the markup.

Things can quickly get out of hand and any changes would take long time to develop, test and deployment.

The new databinding approach comes to rescue this mess.

The New Approach

The address the scenario above, only two additional lines of logic need to be introduced to the code behind:

public class MyPage : System.Web.UI.Page

{

public PersonModel Person { get; set; }

protected override void OnPreRender(EventArgs e)

{

base.OnPreRender(e);

Person = new MyPageController().GetCurrentPerson();  // for the purpose of the page, we are not discussing how the data is retrieved.

DataBindChildren();

}

}

The aspx markup would look like this:

Person's Birthday:  <%# Person.Birthday.ToLongDateString() %>
...
Person's Birthday Date in Short Form: <%# Person.Birthday.ToShortDateString() %>

Why the New Approach

The new approach offers a few advantage over the old approach:

1. Separation of Concerns

The new approach has the code behind focus on gathering the raw data the page would need to render its content.  It, however, does not have to concern about how the content should appear (ie. color, css, or even data formatting).

The markup of the page concerns about how the content (in a model like class) should be rendered, it is not responsible for gathering the data but rendering data as is.

This saves back-end developers from concerning the appearance of the page, but focusing on gathering all the data the page needs, and exposing the data to the markup.

2. Clarity

Because of separation of concern, the markup code becomes clear how the data should be rendered, instead of being intertwined with a page’s life-cycle.  The sample above issues the databind at OnPreRender, this allows all controls properly initialized before data is bound to the controls.

3.  Testable

For developers, because the code-behind is now responsible for data gathering, it is possible to develop unit test to test if the page model has the correct values; as for designers, they can develop mock page model values to ensure that controls are properly rendered.

Advertisements