ASP.NET Web Forms allows you to create web applications in the same way you would create a traditional Windows Forms application. This means that you have a control-based interface and the following two files for each page:
• A user interface (UI) file: Includes the markup and is where you design how your page will look and which controls it will use. This file has the extension .aspx.
• A code-behind file: Includes the code that handles events and interactions of all the objects in the page (this code could be included on the preceding .aspx page, but normally is in a separate file). This file has an extension associated with the programming language, either aspx.cs for C# or aspx.vb for VB.NET.
Whenever ASP.NET processes a page, the page passes through several stages, each of which raises different events to handle the processing of the page and its controls. You write code to handle these events and thus respond to various actions related to the processing of a page. For example, you might write code that gets called when the user clicks a button. When a page is first requested, you often have to initialize data and controls. However, when the page posts back, you don’t need to run this code.
A postback happens when a control on the page raises an event that must be handled by the server. View state is the information about the page control’s status. After each postback, the page view state is modified with the new statuses of all the controls in the page. As a default, the page view state is stored in a hidden field inside each page (see Figure 1-1), and its scope and lifetime are limited to the page it belongs to.
Figure 1-1. The view state’s hidden field
The main use of view state is to preserve form information across postbacks. View state is turned on by default and normally serializes the data in every control on the page regardless of whether it is actually used during a postback. This behavior can be modified, however, as view state can be disabled on a per-control, per-page, or server-wide basis. Also, as a security measure, no sensitive information should be stored in view state because the serialized string can be easily deserialized.
To work effectively with Web Forms, it is very important to understand the page life-cycle events and how they are processed. Table 1-1 lists these events and the effect they have on the page and its controls.
Table 1-1. Page Life-cycle Events
---------------------------------------------------------------------------------------------
Event Description
---------------------------------------------------------------------------------------------
PreInit This is the first real event you might handle for a page. You typically use this event only if you need to dynamically (from code) set values such as master page or theme. This event is also useful when you are working with dynamically created controls for a page. You want to create the controls inside this event.
Init This event fires after each control has been initialized. You can use this event to change initialization values for controls.
InitComplete This event is raised after all initializations of the page and its controls have been completed.
PreLoad This event fires before view state has been loaded for the page and its controls and before postback processing.
Load The page is stable at this time; it has been initialized and its state has been reconstructed. Code inside the page load event typically checks for PostBack and then sets control properties appropriately. The page’s load event is called first, followed by the load event for all the controls on the web page.
Control event(s) ASP.NET now calls any events on the page or its controls that caused the postback to occur. This might be a button’s click event, for example.
LoadComplete This event occurs after all postback data and view state data is loaded into the page and after the Load method has been called for all controls on the page.
PreRender Use this event to perform any updates before the server controls are rendered to the page. Since all server controls know how to render themselves, this event fires just before that so you can modify any default behavior. Render This is a method of the page object and its controls (and not an event). At this point, ASP.NET calls this method on each of the page’s controls. The Render method generates the client-side HTML, Dynamic HTML (DHTML), and script that are necessary to properly display a control at the browser. This method is useful if you are writing your own custom control. You can override this method to influence the HTML generated for the control.
UnLoad This event is used for cleanup code. You use it to release any managed resources in this stage. Managed resources are resources that are handled by the runtime, such as instances of classes created by the .NET CLR.
---------------------------------------------------------------------------------------------
An ASP.NET web application contains several types of files, and each type serves a specific purpose within the application. Table 1-2 lists and describes the most important files in an ASP.NET web application.
Table 1-2. ASP.NET File Types
---------------------------------------------------------------------------------------------
File Type Description
---------------------------------------------------------------------------------------------
.aspx This ASP.NET Web Forms file contains the markup (or UI) of the web page and, optionally, the underlying application code.
aspx.cs or aspx.vb These are the code-behind files.
.cs or .vb These are files for general code classes.
web.config This is the application’s general configuration file. It is an XML file that contains all settings for customizing the connection strings, application settings, security, external assemblies, memory, state management, and so on.
global.asax In this file, you can add code for event handlers at the application level. Events are those for when the application starts or ends or when an error is thrown. You can also define Session State events for when a session starts or ends.
.ascx These are user control files. In these files, you can create small pieces of UI real state (e.g. a reusable address panel) the same way as with a full .aspx page, but the difference is that they cannot be accessed directly and must be hosted inside .aspx pages. You can reuse these user controls in any page of your applications.
.asmx or .svc ASMX files are ASP.NET web services, introduce in .NET 2.0. These files provide services for pages in the application or any other program that can access them. ASMX web services are now being replaced by Windows Communication Foundation (WCF) services (introduced in .NET 3.0), which have the extension .svc and offer much-improved security and scalability features.
.master Master pages are like ASPX pages but are used as templates for other pages, having the look and feel and base functionality.
---------------------------------------------------------------------------------------------
We can create two types of ASP.NET web applications in Visual Studio:
• ASP.NET web sites
• ASP.NET web applications
Web sites are preferable in certain scenarios, including the following:
• You want to include both C# and Visual Basic code in a single web project. (By default, a web application is compiled based on language settings in the project file. Exceptions can be made, but making an exception is relatively difficult.)
• You want to open the production site in Visual Studio and update it in real time by using FTP.
• You do not want to have to explicitly compile the project in order to deploy it.
• If you do precompile the site, you want the compiler to create multiple assemblies for the site, which can include one assembly per page or user control, or one or more assemblies per folder.
• You want to be able to update individual files in production by just copying new versions to the production server, or by editing the files directly on the production server.
• If you precompile the site, you want to be able to update individual ASP.NET web pages (ASPX files) without having to recompile the entire site.
• You like to keep your source code on the production server because it can serve as an additional backup copy.
Web applications, on the other hand, offer better functionality if
• You want to be able to use the Edit and Continue feature of the Visual Studio debugger.
• You want to run unit tests on code that is in the class files that are associated with ASP.NET pages.
• You want to refer to the classes that are associated with pages and user controls from stand-alone classes.
• You want to establish project dependencies between multiple web projects.
• You want the compiler to create a single assembly for the entire site.
• You want control over the assembly name and version number generated for the site.
• You want to use MSBuild or Team Foundation Build to compile the project. For example, you might want to add prebuild and postbuild steps.
• You want to avoid putting source code on a production server.
Another important choice to make is the type of controls we’ll have in our application. We can choose HTML or web server controls, or both. In general, a Web Forms web page can contain basic controls such as <input type="text"../>, which are standard to HTML, and/or much more powerful web server controls such as <asp:TextBox . . . />. The difference between the two types of controls is functionality. HTML controls have limited functionality because they work only on the client (browser), while web server controls work on both the client and the server. Web server controls are the only ones that are accessible in the code-behind file of the web page, and they
generate the appropriate HTML markup when rendered to the client.
Consider using HTML controls when any of the following conditions exists:
• You are migrating existing, classic ASP pages over to ASP.NET.
• The control needs to have custom client-side JavaScript attached to the control’s events.
• The web page has lots of client-side JavaScript that is referencing the control.
In nearly all other cases, you should consider using the more powerful web server controls, which follow a programming model and naming standard similar to Windows Forms. A web server control can generate extremely complex HTML markup. For example, <asp:Calendar> renders a <table> with multiple <tr> and <td> elements. These controls also have other benefits, such as multi browser rendering support, a powerful programming model, layout control, and theme support.
• A user interface (UI) file: Includes the markup and is where you design how your page will look and which controls it will use. This file has the extension .aspx.
• A code-behind file: Includes the code that handles events and interactions of all the objects in the page (this code could be included on the preceding .aspx page, but normally is in a separate file). This file has an extension associated with the programming language, either aspx.cs for C# or aspx.vb for VB.NET.
Whenever ASP.NET processes a page, the page passes through several stages, each of which raises different events to handle the processing of the page and its controls. You write code to handle these events and thus respond to various actions related to the processing of a page. For example, you might write code that gets called when the user clicks a button. When a page is first requested, you often have to initialize data and controls. However, when the page posts back, you don’t need to run this code.
Figure 1-1. The view state’s hidden field
The main use of view state is to preserve form information across postbacks. View state is turned on by default and normally serializes the data in every control on the page regardless of whether it is actually used during a postback. This behavior can be modified, however, as view state can be disabled on a per-control, per-page, or server-wide basis. Also, as a security measure, no sensitive information should be stored in view state because the serialized string can be easily deserialized.
To work effectively with Web Forms, it is very important to understand the page life-cycle events and how they are processed. Table 1-1 lists these events and the effect they have on the page and its controls.
Table 1-1. Page Life-cycle Events
---------------------------------------------------------------------------------------------
Event Description
---------------------------------------------------------------------------------------------
PreInit This is the first real event you might handle for a page. You typically use this event only if you need to dynamically (from code) set values such as master page or theme. This event is also useful when you are working with dynamically created controls for a page. You want to create the controls inside this event.
Init This event fires after each control has been initialized. You can use this event to change initialization values for controls.
InitComplete This event is raised after all initializations of the page and its controls have been completed.
PreLoad This event fires before view state has been loaded for the page and its controls and before postback processing.
Load The page is stable at this time; it has been initialized and its state has been reconstructed. Code inside the page load event typically checks for PostBack and then sets control properties appropriately. The page’s load event is called first, followed by the load event for all the controls on the web page.
Control event(s) ASP.NET now calls any events on the page or its controls that caused the postback to occur. This might be a button’s click event, for example.
LoadComplete This event occurs after all postback data and view state data is loaded into the page and after the Load method has been called for all controls on the page.
PreRender Use this event to perform any updates before the server controls are rendered to the page. Since all server controls know how to render themselves, this event fires just before that so you can modify any default behavior. Render This is a method of the page object and its controls (and not an event). At this point, ASP.NET calls this method on each of the page’s controls. The Render method generates the client-side HTML, Dynamic HTML (DHTML), and script that are necessary to properly display a control at the browser. This method is useful if you are writing your own custom control. You can override this method to influence the HTML generated for the control.
UnLoad This event is used for cleanup code. You use it to release any managed resources in this stage. Managed resources are resources that are handled by the runtime, such as instances of classes created by the .NET CLR.
---------------------------------------------------------------------------------------------
An ASP.NET web application contains several types of files, and each type serves a specific purpose within the application. Table 1-2 lists and describes the most important files in an ASP.NET web application.
Table 1-2. ASP.NET File Types
---------------------------------------------------------------------------------------------
File Type Description
---------------------------------------------------------------------------------------------
.aspx This ASP.NET Web Forms file contains the markup (or UI) of the web page and, optionally, the underlying application code.
aspx.cs or aspx.vb These are the code-behind files.
.cs or .vb These are files for general code classes.
web.config This is the application’s general configuration file. It is an XML file that contains all settings for customizing the connection strings, application settings, security, external assemblies, memory, state management, and so on.
global.asax In this file, you can add code for event handlers at the application level. Events are those for when the application starts or ends or when an error is thrown. You can also define Session State events for when a session starts or ends.
.ascx These are user control files. In these files, you can create small pieces of UI real state (e.g. a reusable address panel) the same way as with a full .aspx page, but the difference is that they cannot be accessed directly and must be hosted inside .aspx pages. You can reuse these user controls in any page of your applications.
.asmx or .svc ASMX files are ASP.NET web services, introduce in .NET 2.0. These files provide services for pages in the application or any other program that can access them. ASMX web services are now being replaced by Windows Communication Foundation (WCF) services (introduced in .NET 3.0), which have the extension .svc and offer much-improved security and scalability features.
.master Master pages are like ASPX pages but are used as templates for other pages, having the look and feel and base functionality.
---------------------------------------------------------------------------------------------
We can create two types of ASP.NET web applications in Visual Studio:
• ASP.NET web sites
• ASP.NET web applications
Web sites are preferable in certain scenarios, including the following:
• You want to include both C# and Visual Basic code in a single web project. (By default, a web application is compiled based on language settings in the project file. Exceptions can be made, but making an exception is relatively difficult.)
• You want to open the production site in Visual Studio and update it in real time by using FTP.
• You do not want to have to explicitly compile the project in order to deploy it.
• If you do precompile the site, you want the compiler to create multiple assemblies for the site, which can include one assembly per page or user control, or one or more assemblies per folder.
• You want to be able to update individual files in production by just copying new versions to the production server, or by editing the files directly on the production server.
• If you precompile the site, you want to be able to update individual ASP.NET web pages (ASPX files) without having to recompile the entire site.
• You like to keep your source code on the production server because it can serve as an additional backup copy.
Web applications, on the other hand, offer better functionality if
• You want to be able to use the Edit and Continue feature of the Visual Studio debugger.
• You want to run unit tests on code that is in the class files that are associated with ASP.NET pages.
• You want to refer to the classes that are associated with pages and user controls from stand-alone classes.
• You want to establish project dependencies between multiple web projects.
• You want the compiler to create a single assembly for the entire site.
• You want control over the assembly name and version number generated for the site.
• You want to use MSBuild or Team Foundation Build to compile the project. For example, you might want to add prebuild and postbuild steps.
• You want to avoid putting source code on a production server.
Another important choice to make is the type of controls we’ll have in our application. We can choose HTML or web server controls, or both. In general, a Web Forms web page can contain basic controls such as <input type="text"../>, which are standard to HTML, and/or much more powerful web server controls such as <asp:TextBox . . . />. The difference between the two types of controls is functionality. HTML controls have limited functionality because they work only on the client (browser), while web server controls work on both the client and the server. Web server controls are the only ones that are accessible in the code-behind file of the web page, and they
generate the appropriate HTML markup when rendered to the client.
Consider using HTML controls when any of the following conditions exists:
• You are migrating existing, classic ASP pages over to ASP.NET.
• The control needs to have custom client-side JavaScript attached to the control’s events.
• The web page has lots of client-side JavaScript that is referencing the control.
In nearly all other cases, you should consider using the more powerful web server controls, which follow a programming model and naming standard similar to Windows Forms. A web server control can generate extremely complex HTML markup. For example, <asp:Calendar> renders a <table> with multiple <tr> and <td> elements. These controls also have other benefits, such as multi browser rendering support, a powerful programming model, layout control, and theme support.
No comments:
Post a Comment