It is often the case that Web developers do not have the aesthetic sense nor the understandings of cognitive psychology to create attractive, user-friendly Web sites. For this reason, many companies divide the work of Web site development between two individuals or teams, one responsible for design features, the other for technical details. In other words, a Web page is divided into presentation and application logic components, each of which is handled by separate individuals or groups. In short, the HTML portion of a page is separated from the script portion of a page such that each can be designed and coded independently of the other.
This idea of separating presentation from application logic is inherent in ASP.NET pages that include both. The use of server controls enforces this separation. There is physical separation between the controls residing in the <HTML> section of a page and the programming of those controls in the <SCRIPT> section of the page. Still, ASP.NET goes a step further. Techniques exist to divide presentation from application logic as independent files. This separation permits two teams of developers to work independently on these two different aspects of page design, and to have them brought together as a functional whole when the page is accessed over the Web.
This feature of ASP.NET is called code-behind development. Using the code-behind approach you can place your page's application logic (its scripting) into a separate file from your page's content presentation (its XHTML code and server controls). Even if you have responsibility for both aspects of page design, the use of code-behind encourages development of standardized processing components that can be reused on multiple Web pages.
Creating a Code-Behind Application
Consider first a very simple application created as a standard ASP.NET page. In this example, a button click delivers the current date displayed on the page.
<SCRIPT Runat="Server"> Sub Get_The_Date (Src As Object, Args As EventArgs) TheDate.Text = "Today is " & DateString & _ ", courtesy of your on-page script." End Sub </SCRIPT> <html> <body> <form Runat="Server"> <asp:Button Text="Get Date" OnClick="Get_The_Date" Runat="Server"/> <asp:Label id="TheDate" Runat="Server"/> </form> </body> </html>
The first step in creating a code-behind application is to remove the script from the page leaving only the XHTML code and server controls—the user interface portion of the application—in the .aspx document. Assume the name of this document is MyDatePage.aspx. It contains a page directive that links this file with its paired MyDatePage.vb code-behind file that is described below.
<%@ Page Inherits="MyDateClass" src="MyDatePage.vb" %> <html> <body> <form Runat="Server"> <asp:Button Text="Get Date" OnClick="Get_The_Date" Runat="Server"/> <asp:Label id="TheDate" Runat="Server"/> </form> </body> </html>
Next, the script portion of the page is rewritten as a Visual Basic class file and saved with the extension .vb. Assume the name of this file is MyDatePage.vb.
Public Class MyDateClass Inherits Page Protected WithEvents TheDate As Label Sub Get_The_Date (Src As Object, Args As EventArgs) TheDate.Text = "Today is " & DateString & _ ", courtesy of your code-behind page." End Sub End Class
The class definition contains the statement "Inherits Page", meaning that the code-behind file inherits the Page class with all the necessary namespaces to create an ASP.NET page. The statement "Protected WithEvents TheDate As Label" is the link between the script on this page and the <asp:Label id="TheDate"> control on MyDatePage.aspx to which the output message is written. Any references in the class file to controls on the .aspx page must be explicitly declared in this format on the code-behind page. Other than these housekeeping statements, the file contains the same subprogram as appears on the original .aspx page.
The code-behind file can appear in the same directory as the .aspx page or it can be placed in a separate directory. Here, the page is located in the same directory as the page.
Application of the MyDatePage.vb code-behind file is illustration by the following button.
Note that is not necessary to separately compile the MyDatePage.vb since it is dynamically compiled along with MyDatePage.aspx when the latter is initially retrieved for display. If you decide to compile the class, say to distribute the application without revealing the source code, then the resulting .dll file is placed in the application's /bin directory. In this case, the Web page's src attribute is not required since all compiled classes reside in this same /bin directory.
Independence in Code-Behind Files
As you can see in the previous example, there is not total independence between the MyDatePage.aspx page and its MyDatePage.vb class. The latter file must be cognizant of the Label control to which it writes its output. In fact, any page that uses this class file must contain a like-named Label; the date cannot be written just anywhere on the page, nor can it be used for other purposes.
It is easy enough, though, to introduce total independence between the two files, making the MyDatePage.vb class usable by any page for any purpose. The needed change is to replace the subprogram with a function that returns the date to the calling page. Then, the page can do as it pleases with the date.
The following code is a rewrite of MyDatePage.vb in which the connection is broken to the display Label on the calling page.
Public Class MyDateClass2 Inherits Page Function Return_Date() Return "Today is " & DateString & _ ", courtesy of your code-behind function." End Function End Class
In addition, the Web page now requires its own script to respond to the button click and to call the function that is inherited with MyDateClass.
<%@ Page Inherits="MyDateClass" src="MyDatePage.vb" %> <SCRIPT Runat="Server"> Sub Return_The_Date (Src As Object, Args As EventArgs) TheDate.Text = Return_Date() End Sub </SCRIPT> <html> <body> <form Runat="Server"> <asp:Button Text="Get Date" OnClick="Return_The_Date" Runat="Server"/> <asp:Label id="TheDate" Runat="Server"/> </form> </body> </html>
Of course, you can argue that it is just as easy to include the function itself on the Web page rather than inheriting it from an external file. This contention is true for this simple application. However, code-behind applications tend to involve more complex code that is used here. For any complex set of operations that could be applicable to numerous pages, there is efficiency in packaging them in code-behind files rather than duplicating the code on all pages, even if it requires modest on-page scripts to call up that functionality.
It is important to remembered that only one page directive is permitted on a .aspx page. Thus, only one code-behind file can be associated with any one page. However, any number of subprograms and functions can be coded in the code-behind file, thereby servicing any number of .aspx pages.