asp.net 页面请求过程

Page Framework Initialization
This is the stage in which ASP.NET first creates the page. It generates all the controls you have defined
with tags in the .aspx web page. In addition, if the page is not being requested for the first time (in other
words, if it’s a postback), ASP.NET deserializes the view state information and applies it to all the
controls.
At this stage, the Page.Init event fires. However, this event is rarely handled by the web page,
because it’s still too early to perform page initialization. That’s because the control objects may not be
created yet and because the view state information isn’t loaded. CHAPTER 3 ■ WEB FORMS

99
User Code Initialization
At this stage of the processing, the Page.Load event is fired. Most web pages handle this event to perform
any required initialization (such as filling in dynamic text or configuring controls).
The Page.Load event always fires, regardless of whether the page is being requested for the first
time or whether it is being requested as part of a postback. Fortunately, ASP.NET provides a way to
allow programmers to distinguish between the first time the page is loaded and all subsequent loads.
Why is this important? First, since view state is maintained automatically, you have to fetch your data
from a dynamic data source only on the first page load. On a postback, you can simply sit back, relax,
and let ASP.NET restore the control properties for you from the view state. This can provide a dramatic
performance boost if the information is expensive to re-create (for example, if you need to query it
from a database). Second, there are also other scenarios, such as edit forms and drill-down pages, in
which you need the ability to display one interface on a page’s first use and a different interface on
subsequent loads.
To determine the current state of the page, you can check the IsPostBack property of the page,
which will be false the first time the page is requested. Here’s an example:
if (!IsPostBack)
{
// It's safe to initialize the controls for the first time.
FirstName.Text = "Enter your name here";
}
■ Note It’s a common convention to write Page.IsPostBack instead of just IsPostBack. This longer form works
because all web pages are server controls, and all server controls include a Page property that exposes the current
page. In other words, Page.IsPostBack is the same as IsPostBack—some developers simply think the first version
is easier to read. Which approach you use is simply a matter of preference.
Remember, view state stores every changed property. Initializing the control in the Page.Load event
counts as a change, so any control value you touch will be persisted in view state, needlessly enlarging
the size of your page and slowing transmission times. To streamline your view state and keep page sizes
small, avoid initializing controls in code. Instead, set the properties in the control tag (either by editing
the tag by hand in source view or by using the Properties window). That way, these details won’t be
persisted in view state. In cases where it really is easier to initialize the control in code, consider
disabling view state for the control by setting EnableViewState to false and initializing the control every
time the Page.Load event fires, regardless of whether the current request is a postback.
Validation
ASP.NET includes validation controls that can automatically validate other user input controls and
display error messages. These controls fire after the page is loaded but before any other events take
place. However, the validation controls are for the most part self-sufficient, which means you don’t
need to respond to the validation events. Instead, you can just examine whether the page is valid
(using the Page.IsValid property) in another event handler. Chapter 4 discusses the validation controls
in more detail. CHAPTER 3 ■ WEB FORMS

100
Event Handling
At this point, the page is fully loaded and validated. ASP.NET will now fire all the events that have taken
place since the last postback. For the most part, ASP.NET events are of two types:
Immediate response events: These include clicking a submit button or clicking some other button,
image region, or link in a rich web control that triggers a postback by calling the __doPostBack()
JavaScript function.
Change events: These include changing the selection in a control or the text in a text box. These
events fire immediately for web controls if AutoPostBack is set to true. Otherwise, they fire the next
time the page is posted back.
As you can see, ASP.NET’s event model is still quite different from a traditional Windows
environment. In a Windows application, the form state is resident in memory, and the application runs
continuously. That means you can respond to an event immediately. In ASP.NET, everything occurs in
stages, and as a result events are sometimes batched together.
For example, imagine you have a page with a submit button and a text box that doesn’t post back
automatically. You change the text in the text box and then click the submit button. At this point,
ASP.NET raises all of the following events (in this order):
• Page.Init
• Page.Load
• TextBox.TextChanged
• Button.Click
• Page.PreRender
• Page.Unload
Remembering this bit of information can be essential in making your life as an ASP.NET
programmer easier. There is an upside and a downside to the event-driven model. The upside is that the
event model provides a higher level of abstraction, which keeps your code clear of boilerplate code for
maintaining state. The downside is that it’s easy to forget that the event model is really just an
emulation. This can lead you to make an assumption that doesn’t hold true (such as expecting
information to remain in member variables) or a design decision that won’t perform well (such as
storing vast amounts of information in view state).
Automatic Data Binding
In Chapter 9, you’ll learn about the data source controls that automate the data binding process. When
you use the data source controls, ASP.NET automatically performs updates and queries against your
data source as part of the page life cycle.
Essentially, two types of data source operations exist. Any changes (inserts, deletes, or updates) are
performed after all the control events have been handled but just before the Page.PreRender event fires.
Then, after the Page.PreRender event fires, the data source controls perform their queries and insert the
retrieved data into any linked controls. This model makes instinctive sense, because if queries were
executed before updates, you could end up with stale data in your web page. However, this model also
introduces a necessary limitation—none of your other event handlers will have access to the most recent
data, because it hasn’t been retrieved yet.
This is the last stop in the page life cycle. Historically, the Page.PreRender event is supposed to
signify the last action before the page is rendered into HTML (although, as you’ve just learned, some
data binding work can still occur after the prerender stage). During the prerender stage, the page and CHAPTER 3 ■ WEB FORMS

101
control objects are still available, so you can perform last-minute steps such as storing additional
information in view state.
To learn much more about the ASP.NET data binding story, refer to Chapter 9.
Cleanup
At the end of its life cycle, the page is rendered to HTML. After the page has been rendered, the real
cleanup begins, and the Page.Unload event is fired. At this point, the page objects are still available, but
the final HTML is already rendered and can’t be changed.
Remember, the .NET Framework has a garbage collection service that runs periodically to release
memory tied to objects that are no longer referenced. If you have any unmanaged resources to release,
you should make sure you do this explicitly in the cleanup stage or, even better, before. When the
garbage collector collects the page, the Page.Disposed event fires. This is the end of the road for the
web page.