- Understanding Page Events
- Understanding Page Properties
- Understanding Directives
- Code Separation and Using Code-Behind
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Code Separation and Using Code-Behind
As we've discussed before, ASP.NET has provided a really cool way to keep code separate by changing the paradigm from an inline, interpreted language to an object/event-oriented paradigm. But ASP.NET doesn't stop there. It provides another level of separation of code and content if you want to use it. It's called the code-behind technique.
This subject was mentioned briefly in Chapter 1 and also appeared in a little example, but here the code-behind technique is dissected so you can fully understand what's happening.
The following is an example of a typical ASP.NET page that doesn't utilize any code-behind techniques. It has an ASP:Label control that you're familiar with, a few server controls, and a button with a server-side function attached to its onClick event. It's nothing very complicated and its results are pretty predictable, as you can see in Figure 4.10.
){kind=link}
Visual Basic .NET—codebehind_not_vb.aspx
<%@ page language="vb" runat="server"%> <script runat="server"> Sub SubmitThis( s As Object, e As EventArgs ) myLabel.Text = "You Selected: " + myList.SelectedItem.Text + " and " +
myDropdown.SelectedItem.Value End Sub Sub Page_Load myLabel.Text = "" End Sub </script> <html> <head><title>Not Codebehind</title></head> <body> <form Runat="Server"> <asp:Label ID="myLabel" forecolor="Red" font-bold="True" MaintainState="False"
C#—codebehind_not_cs.aspx
<%@ page language="c#" runat="server"%>
<script runat="server">
public void SubmitThis(object s, EventArgs e ){
myLabel.Text = "You Selected: " + myList.SelectedItem.Text + " and " +
myDropdown.SelectedItem.Value;
}
void Page_Load(){
myLabel.Text = "";
}
</script>
<html>
<head><title>Not Code Behind</title></head>
<body>
<form Runat="Server">
<asp:Label ID="myLabel" forecolor="Red" font-bold="True" MaintainState="False"
Runat="Server" />
<br>
<asp:ListBox ID="myList" Runat="Server">
<asp:ListItem Text="Red" />
<asp:ListItem Text="Green" />
<asp:ListItem Text="Blue" />
</asp:ListBox>
<br>
<asp:DropDownList ID="myDropdown" Runat="Server">
<asp:ListItem Text="One" />
<asp:ListItem Text="Two" />
<asp:ListItem Text="Three" />
</asp:DropDownList>
<br>
<asp:Button Text="Place Order" OnClick="SubmitThis" Runat="Server" />
</form>
</body>
</html>
Figure 4.10 A predictable and typical ASP.NET page not utilizing any code-behind techniques.
The following is an example of the preceding page and function, but it uses the code-behind technique to separate logical or programming code from content or display code. The ASP.NET page ends with the .aspx extension. This is the content page. This simple example has the same label, a list box control, a drop-down list control, and a form button on the page. As you can see, there is no programming code on this page, with the exception of the @page directive that describes what class is inherited from the code-behind page and the name of the file that is the code-behind page.
Visual Basic .NET—codebehind_vb.aspx
<%@ page inherits="vbsamplecodebehind" src="codebehind_vb.vb" %> <html> <head><title>Code Behind</title></head> <body> <form Runat="Server"> <asp:Label ID="myLabel" forecolor="Red" font-bold="True" MaintainState="False"
C#—codebehind_cs.aspx
<%@ page inherits="cssamplecodebehind" src="codebehind_cs.cs" %> <html> <head><title>Code Behind</title></head> <body> <form Runat="Server"> <asp:Label ID="myLabel" forecolor="Red" font-bold="True" MaintainState="False"
The line highlighted in bold shows an example of the Inherits directive and Src directive in the @Page portion of the previously discussed directives. The source of the code-behind page is described in the Src value, and the value of inherits describes the class name that you will see in the following code-behind pages. Notice that the class name in the @Page directive is identical to the class name in the code-behind page.
Visual Basic .NET—codebehind_vb.vb
Imports System
Imports System.Web.UI
Imports System.Web.UI.WebControls
Imports System.Web.UI.HtmlControls
Public Class vbsamplecodebehind
Inherits Page
Protected WithEvents myLabel as Label
Protected WithEvents myList as ListBox
Protected WithEvents myDropdown as DropDownList
Sub SubmitThis( s As Object, e As EventArgs )
myLabel.Text = "You Selected: " + myList.SelectedItem.Text + " and " +
myDropdown.SelectedItem.Value
End Sub
Sub Page_Load
myLabel.Text = ""
End Sub
End Class
C#—codebehind_cs.cs
using System;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;
public class cssamplecodebehind : System.Web.UI.Page
{
protected Label myLabel;
protected ListBox myList;
protected DropDownList myDropdown;
public void SubmitThis(object s, EventArgs e )
{
myLabel.Text = "You Selected: " + myList.SelectedItem.Text + " and " +
myDropdown.SelectedItem.Value;
}
void Page_Load()
{
myLabel.Text = "";
}
}
You can see in Figure 4.11 that you will get the exact results you'd expect, and to the user the functionality of the page is identical to that of the page that doesn't use code-behind.
){kind=link}
Figure 4.11 The end user won't know whether you are using code-behind pages or not. The result to them will be the same.
It is very cool that you can separate code out even further than just by having all the logic at the top of the page and the content or display aspects after that, but that doesn't come without a bit of a price.
Like every convenience, it comes at a cost, and with regard to code-behind the cost comes in the form of more typing. I explain as I go through the highlighted portions of the code-behind example.
First (though not part of the price) I'd like you to take notice of the classname called either vbsamplecodebehind or cssamplecodebehind, depending on the language you use. This is the class that is created in the code-behind page and what is inherited in the @page directive in the ASP.NET page with the .aspx extension.
Now on to the price you pay for the additional layer of separation provided by code-behind. First, code-behind pages don't automatically import any namespaces, as .aspx pages do, so you must explicitly include them into your code-behind pages. In Visual Basic .NET you use the Imports keyword to do this and in C# you use the using keyword.
Second, you must create a class to contain the logical code in your code-behind page so that you can inherit this class into your .aspx page.
And third, you must create instances of every object that is in your .aspx page that you will reference in your code-behind page. You do this in the same way that you would create any other object, but you must assure that the name of the object you create in your code-behind page is identical to the ID of your object on the .aspx page.
If your pages are very complex, the number of namespaces and objects you need to create in your code-behind pages can be extensive, and the extra work can outweigh the advantage of being able to separate out your code this way. You'll need to consider this, of course, as part of a personal or team decision on which method you'll use to create your ASP.NET pages, but it's nice to have the options.
Also note that the extension of the code-behind page is either .vb or .cs, depending on what language your code-behind page contains. This extension is what tells the .NET Framework what language your code-behind page contains. Another small nugget of code-behind is that you aren't forced to use the same language your .aspx file uses in your code-behind pages. In other words, you could have easily used a C# code-behind page in a Visual Basic .NET .aspx page or vice-versa. As long as the classname and source in the .aspx page's @page directive correctly match the class of our code-behind page, your page will work properly.