C#城市公交查询系统(文献综述+外文文献翻译+源程序) 第2页
原文摘自：lvar Jacobson.Object-Oriented Software Engineering.第1版.北京：人民邮电出版社，2005.10
外文资料原文
[ASP.NET PAGE OBJECT MODEL:]
Summary: Learn about the eventing model built around ASP.NET Web pages and the various stages that a Web page experiences on its way to HTML. The ASP.NET HTTP run time governs the pipeline of objects that transform the requested URL into a living instance of a page class first, and into plain HTML text next. Discover the events that characterize the lifecycle of a page and how control and page authors can intervene to alter the standard behavior. (6 printed pages)
Introduction: Each request for a Microsoft® ASP.NET page that hits Microsoft® Internet Information Services (IIS) is handed over to the ASP.NET HTTP pipeline. The HTTP pipeline is a chain of managed objects that sequentially process the request and make the transition from a URL to plain HTML text happen. The entry point of the HTTP pipeline is the HttpRuntime class. The ASP.NET infrastructure creates one instance of this class per each AppDomain hosted within the worker process (remember that the worker process maintains one distinct AppDomain per each ASP.NET application currently running).
The HttpRuntime class picks up an HttpApplication object from an internal pool and sets it to work on the request. The main task accomplished by the HTTP application manager is finding out the class that will actually handle the request. When the request is for an .aspx resource, the handler is a page handler—namely, an instance of a class that inherits from Page. The association between types of resources and types of handlers is stored in the configuration file of the application. More exactly, the default set of mappings is defined in the <httpHandlers> section of the machine.config file. However, the application can customize the list of its own HTTP handlers in the local web.config file. The line below illustrates the code that defines the HTTP handler for .aspx resources.
<add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory"/>
An extension can be associated with a handler class, or more in general, with a handler factory class. In all cases, the HttpApplication object in charge for the request gets an object that implements the IHttpHandler interface. If the association resource/class is resolved in terms of a HTTP handler, then the returned class will implement the interface directly. If the resource is bound to a handler factory, an extra step is necessary. A handler factory class implements the IHttpHandlerFactory interface whose GetHandler method will return an IHttpHandler-based object.
How can the HTTP run time close the circle and process the page request? The IHttpHandler interface features the ProcessRequest method. By calling this method on the object that represents the requested page, the ASP.NET infrastructure starts the process that will generate the output for the browser.
The Real Page Class
The type of the HTTP handler for a particular page depends on the URL. The first time the URL is invoked, a new class is composed and dynamically compiled to an assembly. The source code of the class is the outcome of a parsing process that examines the .aspx sources. The class is defined as part of the namespace ASP and is given a name that mimics the original URL. For example, if the URL endpoint is page.aspx, the name of the class is ASP.Page_aspx. The class name, though, can be programmatically controlled by setting the ClassName attribute in the @Page directive.
The base class for the HTTP handler is Page. This class defines the minimum set of methods and properties shared by all page handlers. The Page class implements the IHttpHandler interface.
Under a couple of circumstances, the base class for the actual handler is not Page but a different class. This happens, for example, if code-behind is used. Code-behind is a development technique that insulates the code necessary to a page into a separate C# or Microsoft Visual Basic® .NET class. The code of a page is the set of event handlers and helper methods that actually create the behavior of the page. This code can be defined inline using the <script runat=server> tag or placed in an external class—the code-behind class. A code-behind class is a class that inherits from Page and specializes it with extra methods. When specified, the code-behind class is used as the base class for the HTTP handler.
The other situation in which the HTTP handler is not based on Page is when the configuration file of the application contains a redefinition for the PageBaseType attribute in the <pages> section.
<pages PageBaseType="Classes.MyPage, mypage" />
The PageBaseType attribute indicates the type and the assembly that contains the base class for page handlers. Derived from Page, this class can automatically endow handlers with a custom and extended set of methods and properties.
The Page Lifecycle
Once the HTTP page handler class is fully identified, the ASP.NET run time calls the handler's ProcessRequest method to process the request. Normally, there is no need to change the implementation of the method as it is provided by the Page class.
This implementation begins by calling the method FrameworkInitialize, which builds the controls tree for the page. The method is a protected and virtual member of the TemplateControl class—the class from which Page itself derives. Any dynamically generated handler for an .aspx resource overrides FrameworkInitialize. In this method, the whole control tree for the page is built.
Next, ProcessRequest makes the page transit various phases: initialization, loading of view state information and postback data, loading of the page's user code and execution of postback server-side events. After that, the page enters in rendering mode: the updated view state is collected; the HTML code is generated and then sent to the output console. Finally, the page is unloaded and the request is considered completely served.
During the various phases, the page fires a few events that Web controls and user-defined code can intercept and handle. Some of these events are specific for embedded controls and subsequently can't be handled at the level of the .aspx code.

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ... 下一页  >>