ASP.NET Web Page应用深入探讨第1/2页

一、服务器脚本基础介绍
  首先,我们先复习一下Web服务器页面的基本执行方式:
  1、客户端通过在浏览器的地址栏敲入地址来发送请求到服务器端
  2、服务器接收到请求之后,发给相应的服务器端页面(也就是脚本)来执行,脚本产生客户端的响应,发送回客户端
  3、客户端浏览器接收到服务器传回的响应,对Html进行解析,将图形化的网页呈现在用户面前
  对于服务器和客户端的交互,通常通过下面几种主要方式:
  1、Form:这是最主要的方式,标准化的控件来获取用户的输入,Form的提交将数据发送给服务器端处理
  2、QueryString:通过在Url后面带参数达到将参数传送给服务器,这种方式其实跟Get方式的Form是一样的
  3、Cookies:这是一种比较特殊的方式,通常用于用户身份的确认
  二、ASP.Net简介
  传统的服务器脚本语言,如ASP、JSP等,编写服务器脚本的方式大同小异,都是在Html中嵌入解释或编译执行的代码,由服务器平台执行这些代码来生成Html;对于这类似的脚本,页面的生存周期实际上很简单,就是从开头至末尾,执行完所有的代码,当然用Java编写的Servlet可以编写更复杂的代码,但是从结构上看,和JSP没什么区别。
  ASP.Net的出现,打破了这种传统;ASP.Net采用了CodeBehind技术和服务器端控件,加入了服务器端的事件的概念,改变了脚本语言编写的模式,更加贴近Window编程,使Web编程更加简单、直观;但是我们要看到,ASP.Net本身并没有改变Web编程的基本模式,只是封装了一些细节、提供了一些易用的功能,使代码更容易编写和维护;从某种程度上来说,将服务器端执行的方式复杂化了,这就是我们今天要讨论的主体:ASP.Net Web Page的生存周期。
  三、ASP.Net请求处理模式
  我们说,ASP.Net的Web Page并没有脱离Web编程的模式,所以它仍然是以 请求->接收请求->处理请求->发送响应 这样的模式在工作,每一次与客户端的交互都会引发一次新的请求,所以一个Web Page的生命周期是以一次请求为基础的。
  当IIS收到客户端的请求的时候,会将请求交给aspnet_wp这个进程来处理,这个进程会查看请求的应用程序域是否存在,如果不存在则会创建一个,然后会创建一个Http运行时(HttpRuntime)来处理请求,这个运行时“为当前应用程序提供一组 ASP.NET 运行时服务”(摘自MSDN)。
  HttpRuntime在处理请求的时候,会维护一系列的应用程序实例,也就是应用程序的Global类(global.asax)的实例,这些实例在没有请求的时候,会存放在一个应用程序池中(实际上应用程序池由另一个类来维护,HttpRuntime只是简单的调用),每接收到一个请求,HttpRuntime都会获取一个闲置的实例来处理请求,这个实例在请求结束前不会处理其他的请求,处理完毕之后,它又会回到池中,“一个实例在其生存期内被用于处理多个请求,但它一次只能处理一个请求。”(摘自MSDN)
  当应用程序实例处理请求的时候,它会创建请求页面类的实例,执行它的ProcessRequest方法来处理请求,这个方法也就是Web Page生命周期的开始。
  四、Aspx页面与CodeBehind
  在深入了解页面的生命周期之前,我们先来探讨一些Aspx与CodeBehind之间的关系。
<%@ Page language="c#" Codebehind="WebForm.aspx.cs" Inherits="MyNamespace.WebForm" %>
  相信使用过CodeBehind技术的朋友,对ASPX顶部的这句话应该是非常熟悉了,我们来一项一项的分析它:
  Page language="c#" 这个就不用多说了吧
  Codebehind="WebForm.aspx.cs" 这一句表示绑定的代码文件
  Inherits="MyNamespace.WebForm" 这句非常重要,它表示页面继承的类名称,也就是CodeBehind的代码文件中的类,这个类必须从System.Web.WebControls.Page派生
  从上面我们可以分析出,实际上CodeBehind中的类就是页面(ASPX)的基类,到这里,可能有些朋友要问了,在编写ASPX的时候,完全是按照ASP的方式,在Html中嵌入代码或者嵌入服务器控件,没有看到所谓“类”的影子啊?
  这个问题实际上并不复杂,各位使用ASP.Net编程的朋友可以到你们的系统盘:\WINDOWS\Microsoft.NET\Framework\<版本号>\Temporary ASP.NET Files这个目录下,这个下面就放了所有本机上存在的ASP.Net应用程序的临时文件,子目录的名称就是应用程序的名称,然后再下去两层(为了保证唯一,ASP.Net自动产生了两层子目录,并且子目录名称是随机的),然后我们会发现有很多类似:“yfy1gjhc.dll”、“xeunj5u3.dll”这样的链接库以及“komee-bp.0.cs”、“9falckav.0.cs”这样的源文件,实际上这就是ASPX被ASP.Net动态编译后的结果,打开这些源文件我们可以发现:

public class WebForm_aspx : MyNamespace.WebForm, System.Web.SessionState.IRequiresSessionState

  这就印证了我们前面的说法,ASPX是代码绑定类的子类,它的名称是ASPX文件名加上“_aspx”后缀,通过研究这些代码我们可以发现,实际上所有aspx中定义的服务器控件都是在这些代码中生成的,然后动态产生这些代码的时候,把原来在ASPX中嵌入的代码写在了相应的位置。
  当某个页面第一次被访问的时候,Http运行时就会使用一个代码生成器去解析ASPX文件并生成源代码并编译,然后以后的访问就直接调用编译后的dll,这也是为什么ASPX第一次访问的时候非常慢的原因。
  解释了这个问题,我们再来看另一个问题。我们在使用代码绑定的时候,在设计页面拖一个控件,然后切换到代码视图,就可以直接在Page_Load中使用这个控件了,既然控件是在子类中产生的,那为什么在父类中可以直接使用呢?
  实际上我们可以发现,每当用VS.Net拖一个控件到页面上,代码绑定文件中总是会类似这样的添加一个声明:

protected System.Web.WebControls.Button Button1;

  我们可以发现这个字段被声明成protected,而且名字与ASPX中控件的ID一致,仔细想一想,这个问题就迎刃而解了。我们前面提到ASPX的源代码是被生成器动态生成和编译的,生成器会产生动态生成每一个服务器控件的代码,在生成的时候,它会检查父类有没有声明这个控件,如果声明了,它会添加类似下面的一句代码:

this.DataGrid1 = __ctrl;

  这个__ctrl就是生成该控件的变量,这时候它就把控件的引用赋给了父类中相应的变量,这也是为什么父类中的声明必须为protected(实际上也可以为public),因为要保证子类能够调用。
  然后在执行Page_Load的时候,因为这时候父类的声明已经被子类中的初始化代码赋了值,所以我们就可以使用这个字段来访问对应的控件,了解了这些,我们就不会犯在代码绑定文件中的构造器里使用控件,造成空引用的异常的错误了,因为构造器是最先执行的,这时候子类的初始化还没有开始,所以父类中的字段是空值,至于子类是什么时候初始化我们放到后面讨论。
五、页面生存周期
  现在回到第三个标题中讲到的内容,我们讲到了HttpApplication的实例接收请求,并创建页面类的实例,实际上这个实例也就是动态编译的ASPX的类的一个实例,上一个标题中我们了解到ASPX实际上是代码绑定中类的子类,所以它继承了所有的protected方法。
  现在我们来看看VS.Net自动生成的CodeBehind类的代码,以此来开始我们对页面生命周期的探讨:


代码如下:

#region Web Form Designer generated code
override protected void OnInit(EventArgs e)
{
 //
 // CODEGEN:该调用是 ASP.NET Web 窗体设计器所必需的。
 //
 InitializeComponent();
 base.OnInit(e);
}
/// <summary>
/// 设计器支持所需的方法 - 不要使用代码编辑器修改
/// 此方法的内容。
/// </summary>
private void InitializeComponent()
{
 this.DataGrid1.ItemDataBound += new System.Web.UI.WebControls.DataGridItemEventHandler(this.DataGrid1_ItemDataBound);
 this.Load += new System.EventHandler(this.Page_Load);
}
#endregion

  这个就是使用VS.Net产生的Page的代码,我们来看,这里面有两个方法,一个是OnInit,一个是InitializeComponent,后者被前者调用,实际上这就是页面初始化的开始,在InitializeComponent中我们看到了控件的事件声明和Page的Load声明。
  下面是从MSDN中摘录的一段描述和一个页面生命周期方法和事件触发的顺序表:
  “每次请求 ASP.NET 页时,服务器就会加载一个 ASP.NET 页,并在请求完成时卸载该页。页及其包含的服务器控件负责执行请求并将 HTML 呈现给客户端。虽然客户端和服务器之间的通讯是无状态的和断续的,但是必须使客户感觉到这是一个连续执行的过程。”
  “这种连续性假象是由 ASP.NET 页框架、页及其控件实现的。回发后,控件的行为必须看起来是从上次 Web 请求结束的地方开始的。虽然 ASP.NET 页框架可使执行状态管理相对容易一些,但是为了获得连续性效果,控件开发人员必须知道控件的执行顺序。控件开发人员需要了解:在控件生命周期的各个阶段,控件可使用哪些信息、保持哪些数据、控件呈现时处于哪种状态。例如,在填充页上的控件树之前控件不能调用其父级。” “下表提供了控件生命周期中各阶段的高级概述。有关详细信息,请点击表中的链接。”
阶段 控件需要执行的操作 要重写的方法或事件
初始化 初始化在传入 Web 请求生命周期内所需的设置。请参阅处理继承的事件。 Init 事件(OnInit 方法)
加载视图状态 在此阶段结束时,就会自动填充控件的 ViewState 属性,详见维护控件中的状态中的介绍。控件可以重写 LoadViewState 方法的默认实现,以自定义状态还原。 LoadViewState 方法
处理回发数据 处理传入窗体数据,并相应地更新属性。请参阅处理回发数据。
注意 只有处理回发数据的控件参与此阶段。 LoadPostData 方法 (如果已实现IPostBackDataHandler)
加载 执行所有请求共有的操作,如设置数据库查询。此时,树中的服务器控件已创建并初始化、状态已还原并且窗体控件反映了客户端的数据。请参阅处理继承的事件。 Load 事件
(OnLoad 方法)
发送回发更改通知 引发更改事件以响应当前和以前回发之间的状态更改。请参阅处理回发数据。
注意 只有引发回发更改事件的控件参与此阶段。 RaisePostDataChangedEvent 方法
(如果已实现 IPostBackDataHandler)
处理回发事件 处理引起回发的客户端事件,并在服务器上引发相应的事件。请参阅捕获回发事件。

当前1/2页 12下一页阅读全文

(0)

相关推荐

  • ASP.NET Web Page应用深入探讨第1/2页

    一.服务器脚本基础介绍 首先,我们先复习一下Web服务器页面的基本执行方式: 1.客户端通过在浏览器的地址栏敲入地址来发送请求到服务器端 2.服务器接收到请求之后,发给相应的服务器端页面(也就是脚本)来执行,脚本产生客户端的响应,发送回客户端 3.客户端浏览器接收到服务器传回的响应,对Html进行解析,将图形化的网页呈现在用户面前 对于服务器和客户端的交互,通常通过下面几种主要方式: 1.Form:这是最主要的方式,标准化的控件来获取用户的输入,Form的提交将数据发送给服务器端处理 2.Que

  • 分享提高ASP.NET Web应用性能的技巧

    在这篇文章中,将介绍一些提高 ASP.NET Web 应用性能的方法和技巧.众所周知,解决性能问题是一项繁琐的工作,当出现性能问题,每个人都会归咎于编写代码的开发人员. 那性能问题到底该如何解决?以下是应用系统发布前,作为 .NET 开发人员需要检查的点. 1.debug=「false」 当创建 ASP.NET Web应用程序,默认设置为「true」.开发过程中,设置为「true」是非常有用多,但在应用程序发布部署时,需将其设置为「false」. <compilation defaultLang

  • ASP.NET+Web服务实现软件共享

    摘 要 本文提出一种新的通过软件功能共享而实现软件共享的方法,这种方法的优点是以远程调用Web服务的形式实现软件功能的共享,而不将软件拷贝到客户端,也减小了网络上的一些资源冗余,也有利于共享现有Web服务集成新的系统.而且本文通过学生身份验证模块实例分析了这种新方法的有效性. 引言 传统的软件共享是将软件从网络的服务器拷贝到客户端,以实现软件的共享,这种方法的缺点是每一个需要使用该软件的客户端都必须先拷贝该软件,导致网络上的空间冗余,因而导致产生了大量孤立的数据和重复的业务逻辑. Web ser

  • 支持Ajax跨域访问ASP.NET Web Api 2(Cors)的示例教程

    随着深入使用ASP.NET Web Api,我们可能会在项目中考虑将前端的业务分得更细.比如前端项目使用Angularjs的框架来做UI,而数据则由另一个Web Api 的网站项目来支撑.注意,这里是两个Web网站项目了,前端项目主要负责界面的呈现和一些前端的相应业务逻辑处理,而Web Api则负责提供数据. 这样问题就来了,如果前端通过ajax访问Web Api项目话,就涉及到跨域了.我们知道,如果直接访问,正常情况下Web Api是不允许这样做的,这涉及到安全问题.所以,今天我们这篇文章的主

  • ASP.NET Web页生命周期和执行的方法介绍

    以上所列的阶段中有些在页面级是不可见的,并且仅对服务器控件的编写者和要创建从 Page 导出的类的开发人员有意义.Init.Load.PreRender.Unload,再加上由嵌入式控件定义的所有回发事件,就构成了向外发送页面的各个阶段标记. 执行的各个阶段 页面生命周期中的第一个阶段是初始化.这个阶段的标志是 Init 事件.在成功创建页面的控件树后,将对应用程序触发此事件.换句话说,当 Init 事件发生时,.aspx 源文件中静态声明的所有控件都已实例化并采用各自的默认值.控件可以截取 I

  • 推荐8项提高 ASP.NET Web API 性能的技术

    在本文中,我将介绍8项提高 ASP.NET Web API 性能的技术. 1) 使用最快的 JSON 序列化工具 JSON 的序列化对整个 ASP.NET Web API 的性能有着关键性的影响.在我的一个项目里,我从JSON.NET 序列化工具转到了ServiceStack.Text有一年半了. 我测量过,Web API 的性能提升了20%左右.我强烈建议你去尝试一下这个序列化工具.这里有一些最近的流行序列化工具性能的比较数据. 来源:theburningmonk 更新: 似乎It seams

  • 创建一个完整的ASP.NET Web API项目

    Visual Studio为我们提供了专门用于创建ASP.NET Web API应用的项目模板,借助于此项目模板提供的向导,我们可以"一键式"创建一个完整的ASP.NET Web API项目.在项目创建过程中,Visual Studio会自动为我们添加必要的程序集引用和配置,甚至会为我们自动生成相关的代码,总之一句话:这种通过向导生成的项目在被创建之后其本身就是一个可执行的应用. 一.通过VS2013..NET 4.5.1创建一个Web API项目 1.解决方案下面新建项目 2.选择项

  • 在ASP.Net Web Forms中使用依赖注入的步骤

    目录 创建 WebForm 项目 创建实体 和 接口 创建容器和类型注册 WebForms 使用依赖注入 依赖注入技术就是将一个对象注入到一个需要它的对象中,同时它也是控制反转的一种实现,显而易见,这样可以实现对象之间的解耦并且更方便测试和维护,依赖注入的原则早已经指出了,应用程序的高层模块不依赖于低层模块,而应该统一依赖于抽象或者接口. 在 .Net Framework 4.7.2 中引入了对依赖注入的支持,终于在 ASP.Net Web Forms 中可以使用依赖注入机制了,这篇文章将会讨论

  • ASP.NET Web Api 2实现多文件打包并下载文件的实例

    最近由于工作和个人事务,站点也好久没更新了,但这并不影响我对.NET的热情.站点的更新工作还是得想办法抽时间来完成的. 今天利用中午的时间来写一篇关于Asp.Net Web Api下载文件的文章,之前我也写过类似的文章,请见:<ASP.NET(C#) Web Api通过文件流下载文件的实例> 本文以这篇文章的基础,提供了ByteArrayContent的下载以及在下载多个文件时实现在服务器对多文件进行压缩打包后下载的功能. 关于本文中实现的在服务器端用.NET压缩打包文件功能的过程中,使用到了

  • ASP.NET Web.config配置文件详解

    分析: .NET Web 应用程序的配置信息(如最常用的设置ASP.Net Web 应用程序的身份验证方式),它可以出现在应用程序的每一个目录中.当你通过VB.NET新 建 一个Web应用程序后,默认情况下会在根目录自动创建一个默认的Web.config文件,包括默认的配置设置,所有的子目录都继承它的配置设置.如果你想修改子目录的配置设置, 你可以 在该子目录下新建一个 Web.config文件.它可以提供除从父目录继承的配置信息以外的配置信息,也可以重写或修改父目录中定义的设置.      

随机推荐