WindowsDevCenter.com
oreilly.comSafari Books Online.Conferences.

advertisement


AddThis Social Bookmark Button

Writing ASP.NET Web Forms with C#
Pages: 1, 2, 3, 4, 5, 6

The @ Assembly Directive

The @ Assembly directive declaratively links an assembly to the current page, making all of the assembly's classes and interfaces available for use on the page. You can also use this directive to register assemblies in the configuration file, to link assemblies across the entire application.

The @OutputCache Directive

The @ OutputCache directive declaratively controls the output-caching policies of a page.

<%@ OutputCache Error! Hyperlink reference not valid.="cachetime" Error! Hyperlink reference not valid.="headers" %>

Attributes

  • Duration -- The time (in seconds) that the output cache for the page will be maintained.
  • Vary -- A semicolon-separated list of HTTP headers used to vary the output cache.

The following example would keep items in a page's output cache for 10 seconds.

<%@ OutputCache Duration="10" %>

Separating User Interface and Code

When your application gets more complex, it is recommended that you store your code in a separate file from the user interface. If you are using Visual Studio.NET to develop your Web Forms, the code part is always saved as a different file. If you do this, the class in the code file will extend the Page class. In turn, your aspx file, the page where you put your user interface controls, will extend the class in the code file.

Web Forms allow you to do this by providing the Codebehind and Src attribute of the Page directive. These two attributes act as the glue between your aspx file and your code file. You use Codebehind if your code has already been compiled, and Src if your code exists as source code.

To illustrate the separation of the user interface and code, consider the following example, the code for which is given in Listings 5 and 6.

Listing 5: Testing.aspx

<%@ Page language="c#" Codebehind="MyCode.cs" 
AutoEventWireup="false" Inherits="MyCode" %>
<html>
<head>
<title>Code separation</title>
</head>
<body>
<form runat="server">
<asp:Label id=Label1 runat="server" Width="186" 
Height="19">Label</asp:Label>
<br>
<asp:TextBox id=TextBox1 runat="server"></asp:TextBox>
<asp:Button id=Button1 runat="server" Text="Button"></asp:Button>
</form>
</body>
</html>

Listing 6: MyCode.cs

using System;
using System.Web.UI.WebControls;

public class MyCode : System.Web.UI.Page {
  protected Label Label1;
  protected Button Button1;
  protected TextBox TextBox1;
	
  public MyCode() {
    Page.Init += new System.EventHandler(Page_Init);
  }

  protected void Page_Init(object sender, EventArgs e) {
    Button1.Click += new System.EventHandler (this.Button1_Click);
  }

  public void Button1_Click (object sender, System.EventArgs e) {
    Label1.Text = TextBox1.Text;
  }
}

Listing 4 presents an aspx file that contains some user interface controls: a Label, a TextBox and a Button. No code is present; however, the first line of the page is the Page directive with the Codebehind attribute and the Inherits attribute. The Inherits attribute has the value of "MyCode", telling the compiler that the aspx page is to be compiled as a new class that extends a class named MyCode. This class is to be found in the file given by the Codebehind attribute.

Listing 5 is the code itself. It contains the class MyCode. Note that the class MyCode extends System.Web.UI.Page. This class contains all the needed code to run the application.

If you pre-compile the source code, it has to be compiled into a .dll file and this .dll file should be deployed to the bin subdirectory of the virtual directory.

Session Management

An important feature of Web Forms is the new session-management strategy, the mechanism to retain state between same-user requests. In ASP and other programming technologies, session management using the Session object is not a recommended solution because Session objects are stored in the memory. Therefore, using session management makes your application not scalable. Apart from that, session management relies on cookies to carry session identifiers for each user. This has two serious implications. The user browser has to accept cookies and, in a Web farm environment, there must be a mechanism to redirect subsequent request from the same user to the original server that issues the session identifier.

ASP.NET brings with it a new system of session management that overcomes the disadvantages of Session object-based session management in classic ASP. What is new is that the new feature lets you decide where the user session information will be stored.

You have three options: storing the session information in the memory like in old ASP, in a shared computer's memory, or in a database. These options are known as the session management mode. The three modes are in-process, state server and SQL Server.

Pages: 1, 2, 3, 4, 5, 6

Next Pagearrow