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>
<title> asp.net Inline Pages </title>
<body>
<form id= "Form1" runat= "Server"
<b> Enter Your Name: </b>
<asp:textbox id= "TextBox1" runat= "Server"/>
<asp:button id= "Button1" text= "click Me" runat= "Server"/>
<BR/>
<BR/>
<asp:label id= "Label1" text= "Hello" runat= "Server"/>
</form>
</body>
Note that the button event handler in the example above is located within the <script> </script> 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"%>
<title> asp.net codebehind Pages </title>
<body>
<form runat= "Server" >
<b> Enter Your Name: </b>
<asp:textbox id= "TextBox1" runat= "Server"/>
<asp:button id= "Button1" text= "click Me" runat= "Server"/>
<BR/>
<BR/>
<asp:label id= "Label1" text= "Hello" runat= "Server"/>
</form>
</body>
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.
to share code between pages
Although you can place code in each page of a site (using inline or background code separation models), you may encounter situations where you want to share code across multiple pages of a site. Copying the code to every page that needs it is a inefficient and difficult way to maintain. Luckily, ASP. NET provides several ways to make your code accessible to all of your application's pages.
Code Directory
Pages can be compiled dynamically at run time, and code files (such as. cs and. vb files) are also available. ASP.net 2.0 introduces the App_Code directory, which can contain separate files that contain code that can be accessed by multiple pages of the application. ASP.net 1.x requires these shared files to be precompiled into the bin directory, whereas code files in the App_Code directory are compiled dynamically at run time and are used by the application. It is possible to place code files in multiple languages in the App_Code directory, where they should be placed in different subdirectories (register specific languages in Web.config). The following example shows that using the App_Code directory contains a class file that the page invokes.
<%@ page language= "VB"%>
<script runat= "Server" >
Sub Button1_Click (ByVal sender as Object, ByVal e as System.EventArgs)
Dim C as New Customclass
Label1.Text = C.getmessage (TextBox1.Text)
End Sub
</script>
<title> asp.net Inline Pages </title>
<body>
<form id= "Form1" runat= "Server"
<b> Enter Your Name: </b>
<asp:textbox id= "TextBox1" runat= "Server"/>
<asp:button id= "Button1" text= "click Me" runat= "Server"/>
<BR/>
<BR/>
<asp:label id= "Label1" text= "Hello" runat= "Server"/>
</form>
</body>
By default, the App_Code directory can contain only files in the same language. However, to contain files in multiple languages in the App_Code directory, you can divide the App_Code directory into subdirectories (each subdirectory contains files of the same language). In order to achieve this goal, you must register each subdirectory in the application's Web.config file.
<configuration>
<system.web>
<compilation>
<codeSubDirectories>
<add directoryname= "subdirectory"/>
</codeSubDirectories>
</compilation>
</system.web>
</configuration>
The following example shows a divided App_Code directory that contains both VB and C # language files.
<%@ page language= "VB"%>
<script runat= "Server" >
Sub Button1_Click (ByVal sender as Object, ByVal e as System.EventArgs)
Dim C as New Customclass
Label1.Text = C.getmessage (TextBox1.Text)
Dim C2 as New CustomClass2
Label2.Text = c2. GetMessage (TextBox1.Text)
End Sub
</script>
<title> asp.net Inline Pages </title>
<body>
<form id= "Form1" runat= "Server"
<b> Enter Your Name: </b>
<asp:textbox id= "TextBox1" runat= "Server"/>
<asp:button id= "Button1" text= "click Me" runat= "Server"/>
<BR/>
<BR/>
<asp:label id= "Label1" runat= "Server"/>
<BR/>
<asp:label id= "Label2" runat= "Server"/>
</form>
</body>
Bin directory
Asp. NET first version supports the bin directory, which is similar to the code directory, except that it can contain precompiled parts. It's very useful when you need to use some code from others. In this case, you do not need to access the source code (VB or C # files), but instead use the compiled DLL file. Simply place the part in the Bin directory and use it. By default, all parts in the bin directory are automatically loaded into the application and are available for page access. You need to use the @import instruction at the top of the page to import the name space of the part in the Bin directory.
<@ Import namespace= "Mycustomnamespace"
Global Part caching
. NET Framework component 2.0 contains a large number of components that represent different parts of the frame component. These parts are stored in the global part cache, which is a part warehouse that can be used by all applications on the computer (not for use by a particular application). Several parts of a framework component are automatically used by ASP.net applications. You can register additional parts in the application's Web.config file.
<configuration>
<compilation>
<assemblies>
<add assembly= "System.Data, version=1.0.2411.0, Culture=neutral,
publickeytoken=b77a5c561934e089 "/>
</assemblies>
</compilation>
</configuration>
Note that you must still use the @import directive so that separate pages can use these parts.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
