Separation of inline (Inline) code
The following example shows a simple asp.net page with three server controls (text boxes, buttons, and labels, respectively). Initially, these controls render the same content as the HTML form. However, when you enter a value in the Client text box and click the button, the page is sent back to the server and the click event is processed in the page's code to dynamically update the label control's Text property. The next page will be rendered again to reflect the updated text. This simple example illustrates the rationale behind the server control model, which makes asp.net one of the easiest web programming models to learn and master.
<%@ page language="VB" %>
<script runat="server">
Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs)
Label1.Text = "Hello " & TextBox1.Text
End Sub
</script>
<html>
<head>
<title>ASP.NET Inline Pages</title>
</head>
<body>
<form id="Form1" runat="server">
<h1>Welcome to ASP.NET 2.0!</h1>
<b>Enter Your Name:</b>
<asp:TextBox ID="TextBox1" Runat="server"/>
<asp:Button ID="Button1" Text="Click Me" OnClick="Button1_Click" Runat="server"/>
<br />
<br />
<asp:Label ID="Label1" Text="Hello" Runat="server" />
</form>
</body>
</html>
Note that the button event handler in the example above is located within the tag in the same page that contains the server control. Asp. NET refers to this situation as page programming code inline (Code-inline), which is useful when you want to work with code and display logic in the same file. However, ASP. NET also supports another method for storing your code and displaying content, called the background code (CODE-BEHIND) model. When using the background code, the code that handles the event is located in another physically separate file separated from the server control and the tagged paging file. This clear separation between code and content is useful when you need to maintain these separate files (for example, when multiple individuals are building applications together). In a team project, the designer handles the UI part of the application, and the developer handles the behavior or code is very common, and the background code model is appropriate for this situation.
A simplified background code model
ASP.net 2.0 introduces an improved runtime (runtime) for the background code page, simplifying the connection between the page and the code. In the new background code model, the page is declared as a local (partial) class, allowing the page and code files to be compiled into a class at run time. The page code references the CodeFile property and the background code file in the <%@ page%> directive, specifying the name of the class in the Inherits property. Note that the members of the background code class must be public or protected (protected) and cannot be private.
<%@ page language="VB" CodeFile="CodeBehind_vb.aspx.vb" Inherits="CodeBehind_vb_aspx" %>
<html>
<head>
<title>ASP.NET CodeBehind Pages</title>
</head>
<body>
<form runat="server">
<h1>Welcome to ASP.NET 2.0!</h1>
<b>Enter Your Name:</b>
<asp:TextBox ID="TextBox1" Runat="server"/>
<asp:Button ID="Button1" Text="Click Me" OnClick="Button1_Click" Runat="server"/>
<br />
<br />
<asp:Label ID="Label1" Text="Hello" Runat="server" />
</form>
</body>
</html>
The advantage of a simplified background code model is that you do not have to declare server control variables individually in the background code class. Use the local class (the new attribute in 2.0) to allow the server control ID in the ASPX page to be accessed directly by the background code file. This greatly simplifies the maintenance effort for the background code page.