Almost from it’s beginning, HTML has been a mixture of data, display and logic. While the original static pages might have only combined data and display, once scripting was introduced the three disciplines have lived together uncomfortably. ASP only made this situation worse by introducing a different location (the server) where the scripting code could be executed.
Ugly doesn’t adequately describe this problem. There is little possibility for functional reuse in this scenario. It is difficult even to modify existing business logic, much less make sure that it’s capable of being using by other components. This is not how enterprise-class applications are suppose to be created.
While ASP.NET supports this older processing model (known as in-line), it also introduced a newer model known a code-behind. While this particular model doesn’t eliminate the data/display co-mingling, it does take the business logic away from the web page. Instead, the events are handled by methods in a separate class. The code behind class. Let’s take a brief look at how these pieces (the ASPX page and the code behind class) get wired together.
<%@ Page Language="C#" Inherits="ObjectSharp.WebPageClass" %>
|
Above is a standard, if simplistic, ASPX page. Were it not for that first line, it would look like pretty much a run-of-the-mill HTML page. And it’s that first line that brings the code-behind class into play.
That first line is known as the page directive. When the ASPX file is processed, the directive is interpreted to mean that a) the language in any of the script blocks in the file will be in C# and b) that the processor should use methods in ObjectSharp.WebPageClass to handle the events raised by the web form. As an example, this means that the MyButton_Click method (seen above as the Onclick event handler for MyButton) would be implemented in the assembly that contains the ObjectSharp.WebPageClass class.
using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
namespace ObjectSharp
{
public class WebPageClass : Page
{
protected System.Web.UI.WebControls.Label MyLabel;
protected System.Web.UI.WebControls.Button MyButton;
protected System.Web.UI.WebControls.TextBox MyTextBox;
public void MyButton_Click(Object sender, EventArgs e)
{
MyLabel.Text = MyTextBox.Text.ToString();
}
}
} |
Above is an example of a code-behind file for that example ASPX page. Again, there are a couple of points worth noting. First off, the class itself inherits from System.Web.UI.Page. This is the base page for all ASP.NET code behind files. The fully qualified name for this particular class is ObjectSharp.WebPageClass, which matches the Inherits attribute in the Page directive. There is a public method called MyButton_Click that will be invoked whenever the MyButton control on the web page is clicked.
The final item of note for this class definition are the three protected variables MyLabel, MyButton and MyTextBox. You might have noticed that they correspond, by name and type, to the three elements of the example ASPX page that have asp: as the element’s namespace qualifier. That is not a coincidence. By utilizing that asp: qualifier, a corresponding object is created in the code-behind. Then when the methods of the object are manipulated within the code-behind class, the values on the web page are modified as well.
In the example, the MyButton_Click method sets the Text property on MyLabel. As a result, the MyLabel control on the page that is sent back to the browser will have it’s text updated. This mapping is managed automatically by ASP.NET and has the effect of moving the web page development model much closer to the Windows Forms model. While you can accurately claim that as an abstraction the ASP.NET code-behind model is leaky, as a starting point for ASP.NET developers, it is nice to have a familiar base from which to build.