By: Dan Hurwitz and Jesse Liberty Emailed: 1785 times Printed: 2625 times
In traditional ASP, the interweaving of script with HTML can produce source control nightmares and difficult-to-maintain ASP pages. ASP.NET addresses this problem by giving programmers the ability to separate the executable code from the presentation code. You write the HTML in a page file (with a .aspx extension), and you write the C# or VB.NET code in he code-behind file (with a .cs or .vb extension, depending on its language), which is another way of saying the "code file behind the form."
In the code-behind file, you create a class (which can be any class derived from the Page class) that serves as the base class for the web page you create in the .aspx file. This relationship between your class and the web page is established by a Page directive at the top of the .aspx file:
<%@ Page inherits="CodeBehindDemo" %>
The inherits attribute identifies the class created in the code-behind file from which this .aspx file will derive.
When a web form is compiled, its page is parsed and a new class is generated and compiled. This new class derives from the class identified in the inherits keyword, which in turn derives from System.Web.UI.Page.
Now the only question is, "How does the compiler know where to find this code-behind file class to derive from?" The answer depends on whether or not you are working in the Visual Studio .NET (VS.NET) IDE or using a text editor to work directly with the source files.
If you're working in the VS.NET IDE, then the development environment will automatically pre-compile the class in the code-behind file and use the inherits attribute to point to that class. The .dll file that is created is placed in the \bin subdirectory in the application virtual directory.
You will notice that VS.NET also puts a codebehind attribute in the Page directive, which points to the code-behind file. The codebehind attribute is used to keep track of the code-behind file so that as you make changes to the page, VS.NET can make the appropriate changes to the code-behind file. Using VS.NET will be covered in more detail later in this chapter.
If you are not using a development environment such as VS.NET, but rather editing the files directly in a text editor, then you need to include the src attribute in the Page directive to identify the file containing the class specified in the inherits attribute for the JIT compiler:
<%@ Page inherits="CodeBehindDemo" src="CodeBehind.cs" %>
If the src string does not include a fully qualified path, then the compiler assumes that the file is in the same directory as the .aspx file. If the src attribute is missing, then the compiler will look in the \bin subdirectory of the application virtual directory for a .dll that contains the class marked with the inherits attribute.
In order to convert an .aspx file from in-line code to code-behind, you need to make modifications both to the .aspx file as well as to the code-behind file, as follows:
- Modifications to the .aspx file
The .aspx file needs to have its Page directive modified to include the inherits attribute.
Optionally, the Page directive must be modified to include the src attribute.
- Modifications to the code-behind file
The code-behind file does not automatically inherit the common namespaces used in web forms. The code-behind file itself must tell the compiler which namespaces it needs with the using keyword in C# and the Imports keyword in VB.NET.
The class you create must inherit from the System.Web.UI.Page class.
Every control in the .aspx file referred to by name (id) in the code-behind file must have an accessible variable (declared using either the public or protected access modifier) defined in the code-behind class. The variable type must be the same as the control type, and the variable name must match the control name.
All methods in the code-behind class that are called directly from the .aspx file must be declared as either public or protected methods (that is, using the public or protected access modifiers).
The keywords public, protected, private, and internal (in C#) or friend (in VB) are access modifiers. An access modifier determines which class methods can see and use a member variable or method. Table below summarizes the access modifiers.
The default accessibility of members of a class is private. Thus, if there is no access modifier provided for a class member, then it will be a private member. Regardless of this circumstance, it is always a good idea to explicitly specify the access modifier in order to enhance the readability of the code.
No restrictions. Members marked public are visible to any method of any class.
The members in class A that are marked private are accessible only to methods of class A.
The members in class A that are marked protected are accessible to methods of class A and also to methods of classes derived from class A.
internal (C#) Friend (VB)
The members in class A that are marked internal or friend are accessible to methods of any class in A's assembly.
protected internal (C#) Protected friend (VB)
The members in class A that are marked protected internal or protected friend are accessible only to methods of class A and also to methods of classes derived from class A, and also to any class in A's assembly. This is effectively protected or internal.
Most Viewed Articles (in Asp )
Latest Articles (in Asp)
Comment on this tutorial
- Cloud Computing
- Java Beans
- Mac OS X
- Office 365
- Tech Reviews
Subscribe to Tutorials
1. quite simle to understand. thanks for your explana
View Tutorial By: tapan at 2011-09-29 05:49:48