aspnet生命周期

合集下载

ASP.NETCORE内置的IOC解读及使用

ASP.NETCORE内置的IOC解读及使用

CORE内置的IOC解读及使用在我接触IOC和DI 概念的时候是在2016年有幸倒腾Java的时候第一次接触,当时对这两个概念很是模糊;后来由于各种原因又回到.net 大本营,又再次接触了IOC和DI,也算终于搞清楚了IOC和DI 这两个概念关系。

使用过 Core的人对这两个概念一定不陌生,想必很多人还是很难去理解这两个东西,所以,趁着今天有空,就去把两个概念捋清楚,并将学习过程的知识点记录下来。

一、概念1.1 什么是IOC?Ioc—Inversion of Control,即控制反转,其是一种设计思想,而不是一种技术。

再没有使用IOC之前,我们一般是通过new来实例化,从而创建一个对象。

但是我们使用IOC之后,创建这个对象的控制权将由内部转换到外部,那么这个过程便可以理解为控制反转。

也即把对象转换成抽象对象的依赖.。

同时控制反转也是一个目标,控制反转的优点有如下两点:•可以很好的做到解耦•屏蔽对象的实现细节,只关心动作不关心动作中的细节。

1.2 什么是DI(依赖注入)?全称为Dependency Injection,意思自身对象中的内置对象是通过注入的方式进行创建。

形象的说,即由容器动态的将某个依赖关系注入到组件之中。

1.3 IOC和DI的联系?IOC是一种设计思想,而DI是这种设计思想的一个实现。

理解IOC和DI的关键是:“谁依赖谁,为什么需要依赖,谁注入谁,注入了什么”。

●谁依赖于谁:当然是应用程序依赖于IoC容器;●为什么需要依赖:应用程序需要IoC容器来提供对象需要的外部资源;●谁注入谁:很明显是IoC容器注入应用程序某个对象,应用程序依赖的对象;●注入了什么:就是注入某个对象所需要的外部资源(包括对象、资源、常量数据)1.4 常见的IOC框架。

微软.net core 内置的DI、Autofac、Unity以上已经把IOC和DI 这两个联系简要捋清楚了,下面我们一起学习.net core 内置的DI使用。

asp.netppt课件第3章

asp.netppt课件第3章

6
3.1.3 页面的生命周期
浏览器从Web服务器请求页面时,浏览器和服务器相连的时间 仅够处理请求。Web服务器将页面呈现到浏览器之后,连接即 终止。 页面的生命周期顺序如下。
(1) 开始:在用户访问页面时,页面就进入了开始阶段。在该阶段, 页面将确定请求是发回请求还是新的客户端请求,并设置IsPostBack属 性。 (2) 初始化:在页面开始页面访问之后,会初始化页面属性以及页 面中的服务器控件等内容。 (3) 加载:页面加载控件。 (4) 验证:调用所有的验证程序控件的Validate方法,来设置各个 验证程序控件和页的属性。 (5) 回发事件:在回发事件中,页面会调用处理事件,对数据进行 相应的处理并回发给客户端。 (6) 呈现:获取服务器端回发的数据,呈现在客户端浏览器中,供 用户浏览。 (7) 卸载:完全呈现页面后,将页面发送到客户端并准备丢弃时, 将调用卸载。
16
3.3.4 隐藏域
允许将信息存储在HiddenField控件中,此控件将呈 现为一个标准的HTML 隐藏域。隐藏域在浏览器中不以可见的 形式呈现,可以像对待标准控件一样设置其属性。当向服务器 提交页时,隐藏域的内容将在HTTP窗体集合中随同其他控件 的值一起发送。隐藏域可用作一个储存库,您可以将希望直接 存储在页中的任何特定于页的信息放置到其中。 恶意用户可以很容易地查看和修改隐藏域的内容。请不要在隐 藏域中存储任何敏感信息或保障应用程序正确运行的信息。 HiddenField控件在其Value属性中只存储一个变量,并且必须 通过显式方式添加到页上。 HiddenField控件用于存储一个值,在向服务器的各次发送过 程中,需保持该值。它呈现为<input type=“hidden” />元素。 通常情况下,Web窗体页的状态由视图状态、会话状态和 Cookie来维持。

Web Page的生命周期详解

Web Page的生命周期详解

Web Page的生命周期详解了解 Web Page的生命周期对于一个做WEB开发的工程师来说很有必要,尤其是用于编写自己的control的时候。

Web Page的生命周期可以基本分为以下几个阶段:1. Page request本页面被请求时发生在web page生命周期之前, 当有一个页面被请求时,引擎要判断一下这个页面是否需要经过编译或者直接通过此页面的缓冲版本直接发给请求者。

2. Start在这阶段,Page的Request,Response,IsPostBack,UICulture 属性被适当设置。

3. Page initialization在此阶段,每一个control的UniqueID属性被设置,页面的主题也被应用,如果此页面是回传页面,即Page的IsPostBack属性为true,那么页面里各个控件的新的值和ViewState还没有在此阶段被恢复。

4. Load在此阶段,如果页面是回传页面,择页面里各个控件的新的值和ViewState将被恢复或设置。

5. V alidation在此阶段,页面中验证控件调用自己的Validate方法进行验证以便设置自己的IsValid属性,因为验证控件是在客户端和服务器端都要进行验证的。

6. Postback event handling在此阶段所有的委托事件将被调用,我们所有的事件处理代码是在此时被调用的。

7. Rendering在此阶段Page调用每个控件的Render方法将各个控件对应的html文本流写到Response的OutputStream属性中,在此阶段之前,每个控件将再次保存各自的ViewState,因此我们还是有最后一次机会在Page的PreRender方法中改变控件的ViewState属性的。

8. Unload在此阶段,当初为Page及每个控件建立的实体都将被删除,资源被释放。

aspnet程序设计课程设计

aspnet程序设计课程设计

aspnet程序设计课程设计一、课程目标知识目标:1. 掌握的基本概念、原理及其开发环境配置。

2. 学会使用C#语言进行网页开发,理解服务器控件的使用。

3. 理解并掌握的页面生命周期、事件处理机制及状态管理。

4. 学会使用的内置对象,如Request、Response、Session和Server等。

技能目标:1. 能够独立创建网页,并运用控件构建用户界面。

2. 能够编写事件处理程序,实现用户交互功能。

3. 能够使用状态管理技术,实现不同页面间数据的传递与保存。

4. 能够运用所学的知识解决实际问题,设计并实现简单的应用程序。

情感态度价值观目标:1. 培养学生对程序设计的兴趣,激发学生学习编程的热情。

2. 培养学生的团队协作精神,提高沟通与协作能力。

3. 培养学生勇于探索、积极创新的精神,提高解决问题的能力。

4. 培养学生遵循编程规范,养成良好的编程习惯。

课程性质:本课程为高年级选修课,以实践为主,理论联系实际,注重培养学生的动手能力和创新能力。

学生特点:学生具备一定的编程基础,对网络编程有兴趣,希望学习实际应用开发。

教学要求:结合学生特点,注重理论与实践相结合,通过案例教学,引导学生掌握程序设计的基本知识和技能,培养其解决实际问题的能力。

在教学过程中,关注学生的学习进度和情感态度,鼓励学生积极参与,提高学习效果。

二、教学内容1. 基础知识- 概述与开发环境搭建- C#语言基础及其在中的应用- 服务器控件的使用与事件处理2. 页面生命周期与状态管理- 页面生命周期及各个阶段的作用- 事件处理机制及页面事件的使用- 状态管理技术(如视图状态、隐藏字段、会话状态等)3. 内置对象- Request对象的使用与获取客户端数据- Response对象的使用与发送响应数据- Session对象的使用与管理用户会话状态- Server对象及其他内置对象的功能与应用4. 控件与用户界面设计- 常用控件的使用(如标签、文本框、按钮等)- 数据绑定控件(如GridView、DropDownList等)- 用户控件与自定义控件的设计与应用5. 数据库编程- 概述与数据库连接- 数据命令的执行与数据读取- 数据绑定技术与数据展示6. 实践项目与案例分析- 设计并实现一个简单的博客系统- 分析并优化现有应用程序的案例教学内容安排与进度:第1周:基础知识及开发环境搭建第2周:C#语言基础及其在中的应用第3周:页面生命周期与事件处理第4周:内置对象及其使用方法第5周:控件与用户界面设计第6周:数据库编程第7周:实践项目设计与开发第8周:课程总结与案例分析三、教学方法本课程采用以下多样化的教学方法,旨在激发学生的学习兴趣,提高学生的主动性和实践能力:1. 讲授法:通过教师对的基本概念、原理、技术要点进行系统讲解,帮助学生建立完整的知识体系。

【毕业设计】文献翻译 原文译文(探究ASP-NET-MVC请求的生命周期)

【毕业设计】文献翻译 原文译文(探究ASP-NET-MVC请求的生命周期)

MVC In-Depth: The Life of an MVC Request The purpose of this blog entry is to describe, in painful detail, each step in the life of an MVC request from birth to death. I want to understand everything that happens when you type a URL in a browser and hit the enter key when requesting a page from an MVC website.Why do I care? There are two reasons. First, one of the promises of MVC is that it will b e a very extensible framework. For example, you’ll be able to plug in different view engines to control how your website content is rendered. You also will be able to manipulate how controllers get generated and assigned to particular requests. I want to walk through the steps involved in an MVC page request because I want to discover any and all of these extensibility points.Second, I’m interested in Test-Driven Development. In order to write unit tests for controllers, I need to understand all of the controller dependencies. When writing my tests, I need to mock certain objects using a mocking framework such as Typemock Isolator or Rhino Mocks. If I don’t understand the page request lifecycle, I won’t be able to effectively mock it.Two WarningsB ut first, two warnings.Here's the first warning: I’m writing this blog entry a week after the MVC Preview 2 was publicly released. The MVC framework is still very much in Beta. Therefore, anything that I describe in this blog entry might be outdated and, therefore, wrong in a couple of months. So, if you are reading this blog entry after May 2008, don’t believe everything you read.Second, this blog entry is not meant as an overview of MVC. I describe the lifecycle of an MVC request in excruciating and difficult to read detail. Okay, you have been warned.Overview of the Lifecycle StepsThere are five main steps that happen when you make a request from an MVC website:Step 1 : The RouteTable is CreatedWhen you request a page from a normal application, there is a page on disk that corresponds to each page request. For example, if you request a page named SomePage.aspx then there better be a page named SomePage.aspx sitting on your web server. If not, you receive an error.Technically, an page represents a class. And, not just any class. An page is a handler. In other words, an page implements the IHttpHandler interface and has a ProcessRequest() method that gets called when you request the page. The ProcessRequest() method is responsible for generating the content that gets sent back to the browser.So, the way that a normal application works is simple and intuitive. You request a page, the page request corresponds to a page on disk, the page executes its ProcessRequest() method and content gets sent back to the browser.An MVC application does not work like this. When you request a page from an MVC application, there is no page on disk that corresponds tothe request. Instead, the request is routed to a special class called a controller. The controller is responsible for generating the content that gets sent back to the browser. When you write a normal application, you build a bunch of pages. There is always a one-to-one mapping between URLs and pages. Corresponding to each page request, there better be a page.When you build an MVC application, in contrast, you build a bunch of controllers. The advantage of using controllers is that you can have a many-to-one mapping between URLs and pages. For example, all of the following URLs can be mapped to the same controller:The single controller mapped to these URLs can display product information for the right product by extracting the product Id from the URL. The controller approach is more flexible than the classic approach. The controller approach also results in more readable and intuitive URLs.So, how does a particular page request get routed to a particular controller? An MVC application has something called a Route Table. The Route Table maps particular URLs to particular controllers.An application has one and only one Route Table. This Route Table is setup in the Global.asax file. Listing 1 contains the default Global.asax file that you get when you create a new MVC Web Application project by using Visual Studio.An application’s Route Table is represented by the static RouteTable.Routes property. This property represents a collection of Route objects. In the Global.asax file in Listing 1, two Route objects are added to the Route Table when the application first starts (The Application_Start() method is called only once when the very first page is requested from a website).A Route object is responsible for mapping URLs to handlers. In Listing 1, two Route objects are created. Both Route objects map URLs to the MvcRouteHandler. The first Route maps any URL that follows the pattern {controller}/{action}/{id} to the MvcRouteHandler. The second Route maps the particular URL Default.aspx to the MvcRouteHandler.By the way, this new routing infrastructure can be used independently of an MVC application. The Global.asax file maps URLs to the MvcRouteHandler. However, you have the option of routing URLs to a different type of handler. The routing infrastructure described in this section is contained in a distinct assembly named System.Web.Routing.dll. You can use the routing without using the MVC.Step 2 : The UrlRoutingModule Intercepts the RequestWhenever you make a request against an MVC application, the request is intercepted by the UrlRoutingModule HTTP Module. An HTTP Module is a special type of class that participates in each and every page request. For example, classic includes a FormsAuthenticationModule HTTP Module that is used to implement page access security using Forms Authentication.When the UrlRoutingModule intercepts a request, the first thing the module does is to wrap up the current HttpContext in an HttpContextWrapper2 object. The HttpContextWrapper2 class, unlike the normal HttpContext class, derives from theHttpContextBase class. Creating a wrapper for HttpContext makes it easier to mock the class when you are using a Mock Object Framework such as Typemock Isolator or Rhino Mocks.Next, the module passes the wrapped HttpContext to the RouteTable that was setup in the previous step. The HttpContext includes the URL, form parameters, query string parameters, and cookies associated with the current request. If a match can be made between the current request and one of the Route objects in the Route Table, then a RouteData object is returned.If the UrlRoutingModule successfully retrieves a RouteData object then the module next creates a RouteContext object that represents the current HttpContext and RouteData. The module then instantiates a new HttpHandler based on the RouteTable and passes the RouteContext to the new handler’s constructor.In the case of an MVC application, the handler returned from the RouteTable will always be an MvcHandler. Whenever the UrlRoutingModule can match the current request against a Route in the Route Table, an MvcHandler is instantiated with the current RouteContext.The last step that the module performs is setting the MvcHandler as the current HTTP Handler. An application calls the ProcessRequest() method automatically on the current HTTP Handler which leads us to the next step.Step 3 : The MvcHandler ExecutesIn the previous step, an MvcHandler that represents a particular RouteContext was set as the current HTTP Handler. An application always fires off a certain series of events including Start, BeginRequest, PostResolveRequestCache, PostMapRequestHandler, PreRequestHandlerExecute, and EndRequest events (there are a lot of application events – for a complete list, lookup the HttpApplication class in the Microsoft Visual Studio 2008 Documentation).Everything described in the previous section happens during the PostResolveRequestCache and PostMapRequestHandler events. The ProcessRequest() method is called on the current HTTP Handler right after the PreRequestHandlerExecute event.When ProcessRequest() is called on the MvcHandler object created in the previous section, a new controller is created. The controller is created from a ControllerFactory. This is an extensibility point since you can create your own ControllerFactory. The default ControllerFactory is named, appropriately enough, DefaultControllerFactory.The RequestContext and the name of the controller are passed to the ControllerFactory.CreateController() method to get a particular controller. Next, a ControllerContext object is constructed from the RequestContext and the controller. Finally, the Execute() method is called on the controller class. The ControllerContext is passed to the Execute() method when the Execute() method is called.Step 4 : The Controller ExecutesThe Execute() method starts by creating the TempData object (called the Flash object in the Ruby on Rails world). The TempData can be used to store temporary data that must be used with the very next request (TempData is like Session State with no long-term memory).Next, the Execute() method builds a list of parameters from the request. These parameters, extracted from the request parameters, will act as method parameters. The parameters will be passed to whatever controller method gets executed.The Execute() method finds a method of the controller to execute by using reflection on the controller class (.NET reflection and not navel gazing reflection). The controller class is something that you wrote. So the Execute() method finds one of the methods that you wrote for your controller class and executes it. The Execute() method will not execute any controller methods that are decorated with the NonAction attribute.At this point in the lifecycle, we’ve entered your application code.Step 5 : The RenderView Method is CalledNormally, your controller methods end with a call to either the RenderView() or RedirectToAction() method. The RenderView() method is responsible for rendering a view (a page) to the browser.When you call a controller’s RenderView() method, the call is delegated to the current ViewEngine’s RenderView() method. The ViewEngine is another extensibility point. The default ViewEngine is the WebFormViewEngine. However, you can use another ViewEngine such as the NHaml ViewEngine.The WebFormViewEngine.RenderView() method uses a class named the ViewLocator class to find the view. Next, it uses a BuildManager to create an instance of a ViewPage class from its path. Next, if the page has a master page, the location of the master page is set (again, using the ViewLocator class). If the page has ViewData, the ViewData is set. Finally, the RenderView() method is called on the ViewPage.The ViewPage class derives from the base System.Web.UI.Page class. This is the same class that is used for pages in classic . The final action that RenderView() method performs is to call ProcessRequest() on the page class. Calling ProcessRequest() generates content from the view in the same way that content is generated from a normal page.SummaryThe goal of this blog entry was to describe the entire life of an MVC request from birth to death. I examined the five steps involved in processing an MVC request: Creating the RouteTable, Intercepting the request with the UrlRoutingModule, Generating a Controller, Executing an Action, and Rendering a View.探究 MVC: MVC请求的生命周期本书详细描述了 MVC请求从开始到结束的整个过程,当你在浏览器上输入URL地址并且在网站请求页面敲击回车时,这个过程就产生了。

《ASPNET程序设计》

《ASPNET程序设计》

《ASPNET程序设计》ASPNET程序设计第一章简介1.1 ASPNET简介1.2 ASPNET的优势1.3 ASPNET的架构1.4 ASPNET的基本概念第二章 ASPNET的开发环境2.1 :NET Framework介绍2.2 开发工具的选择2.3 学习资源推荐第三章 ASPNET控件3.1 常用控件介绍3.1.1 标签控件3.1.2 输入控件3.1.3 数据控件3.2 控件的属性和事件3.3 控件的布局和样式第四章 ASPNET页面生命周期4.1 页面生命周期的理解4.2 页面事件的处理4.3 页面的状态管理第五章 ASPNET数据访问5.1 数据库连接与操作5.2 数据绑定与展示5.3 数据验证与处理第六章 ASPNET安全性6.1 认证与授权6.2 安全性的配置与管理6.3 常见安全漏洞与防护第七章 ASPNET性能优化7.1 网页加载速度优化7.2 数据库查询性能优化7.3 缓存的使用与优化第八章 ASPNET部署与发布8.1 服务器环境的准备8.2 项目的部署与发布8.3 常见部署问题与解决方案第九章 ASPNET常见问题与解决方法9.1 常见错误代码解析9.2 调试技巧与注意事项9.3 常见问题及解决方案汇总第十章 ASPNET扩展与进阶10:1 自定义控件开发与使用10:2 多线程与异步编程10:3 国际化与本地化附件:1:示例代码:包含本文档中提到的示例代码,以便读者实践。

2:示例项目:完整的ASPNET项目,供读者参考和学习。

法律名词及注释:1: ASPNET:Active Server Pages :NET,是微软推出的用于开发基于Web的应用程序的技术框架。

2::NET Framework:一种软件开发框架,提供了一个面向对象的编程模型,用于构建Windows应用程序、Web应用程序和服务。

ASP-NET简答题整理Word版

问答题中页面传值有几种方式?1)使用QueryString, 如....?id=1; response. Redirect()....2)使用Session变量3)使用Server.Transfer4)Cookie5)Application6)HiddenField etc(.net 2.0)7)Response.Redirect()方式2. 如果关闭客户端的cookie,Session是否仍然可以使用?如果不可以请说出为什么?如果可以请说出如何使用?不可以,Session真正的数据是存储在服务器上的,但每个Session都对应了一个由Web服务器指定的唯一识别符SeesionID,而在浏览器里是使用Cookie来存储这个SeesionID的.所以使用Session,浏览器必须支持Cookie.3. 默认情况下是如何在客户端和服务器端之间保持数据的?使用ViewState,ViewState是中对同一个窗体页的多次回发(PostBack)之间维持页及控件状态的一种机制4. 请大致描述一下的页面生命周期?页请求、开始、页初始化、加载、验证、回发事件处理、卸载5.请说说Response.Redirect和Server.Transfer有什么区别?能说说它们的实现原理吗?1)Redirect重定向发生在客户端,可以在地址栏中看出网址发生变化,而其他两个看不出来2)Redirect()和Transfer()执行完不会返回原网页,而Execute()会返回原网页3)Redirect()既能重定向到同一网站的不同网页,也能定向到其他网站的其他网页,而其余两个只能定向到同一网站的不同网页4)利用Redirect()在不同页面传输数据时,状态管理采用查询字符串形式原理: Server.Transfer()是在两个页面之间进行传值的好方法,从A页面Transfer到B页面时,就可以在B页面通过Context.Handler获得A页面的一个类的实例,从而在B调用A的各个成员对象。

第3章 ASP.NET页面剖析

第3章页面剖析在Web应用程序上下文中,页面会在第一次被请求时,按需被动态编译。

动态编译并不是A 页面(.aspx文件)特有的,还发生在.NET Web服务(.asmx文件)、Web用户控件(.ascx文件)、HTTP处理程序(.ashx文件),以及其他几种应用程序文件(如global.asax文件)身上。

运行时管道模型负责处理输入的(incoming)HTTP数据包,使其从一个简单的特定协议有效负载转化为服务器端对象——准确地说,是一个系统Page类的派生类的实例。

中的HTTP运行库会处理页面对象,将生成的标记插入响应序列中。

处理用户代码的若干事件标志着响应序列的生成各个阶段,整个过程称为“页面的生命周期”(page life cycle)。

本章会介绍如何将.aspx页面的HTTP请求映射为页面对象、Page类的编程接口,以及如何通过页面生命周期中的事件处理控制标记的生成。

3.1 页面的调用先让我们具体认识一下.aspx页面是如何被转化为类并编译为程序集的。

特定.aspx资源的程序集的生成,分为两个步骤进行。

首先,该资源文件的源代码会被解析,根据得到的信息,从Page类(或P age的派生类)派生出相应的类。

然后,动态生成的类会被编译为程序集,该程序集之后会被缓存到A 专用的临时目录下。

只要链接的(linked).aspx源文件没有被更改,且整个应用程序没有重启,已编译的页面就一直存在。

对已链接的.aspx文件的任何更改,将使相关程序集变为无效,并在该页面下一次被请求时,强制HTTP运行库创建新的程序集。

【89】提示:编辑web.config和global.asax之类的文件会导致整个应用程序重启。

在这种情况下,在某个页面被请求时,所有页面会被重新编译。

如果Bin文件夹中的程序集被改动(新建或被替换),所有页面也会被重新编译。

3.1.1 运行机制能够通过基于Internet信息服务(IIS)的Web服务器访问的所有资源,会按扩展名进行组织。

ASPNET页面事件执行过程

页面事件执行过程是一种用于创建强大和动态的Web应用程序的框架。

它提供了一系列事件来处理页面生命周期中的不同阶段,以及用户交互时的动作。

本文将解释页面事件的执行过程,并介绍每个事件的作用和执行顺序。

页面生命周期在了解页面事件的执行过程之前,我们先来了解一下页面的生命周期。

页面生命周期分为以下几个阶段:1.初始化阶段(Init):在这个阶段,页面和控件的状态会被还原,对于初次访问的页面,还会创建和加载控件。

2.加载视图状态阶段(LoadViewState):在这个阶段,控件的视图状态会被加载,从请求中恢复控件的状态。

3.加载控件阶段(LoadControlState):在这个阶段,控件的控件状态会被加载,从请求中恢复控件的状态。

4.预加载阶段(PreLoad):在这个阶段,控件的数据绑定和页面的一些准备工作会被执行。

5.加载阶段(Load):在这个阶段,控件和页面的相关事件会被触发。

6.事件处理阶段(Event):在这个阶段,处理控件和页面的事件。

7.渲染阶段(Render):在这个阶段,页面和控件的状态信息会被写入到响应中。

8.卸载阶段(Unload):在这个阶段,释放页面和控件的资源。

页面事件在页面生命周期中的不同阶段,会触发一系列的事件,用于执行特定的功能和任务。

以下是一些常见的页面事件:1.Page_Init:在页面初始化阶段触发,用于初始化页面和控件的状态。

2.Control_Init:在控件初始化阶段触发,用于初始化控件的状态。

3.Page_Load:在页面加载阶段触发,用于加载数据和处理其他与页面相关的事件。

4.Control_Load:在控件加载阶段触发,用于加载控件的数据和处理其他与控件相关的事件。

5.Page_PreRender:在页面预渲染阶段触发,用于最后一次修改页面和控件的状态。

6.Control_PreRender:在控件预渲染阶段触发,用于最后一次修改控件的状态。

7.Page_Unload:在页面卸载阶段触发,用于释放资源和执行其他页面相关的清理工作。

aspnet面试题

aspnet面试题面试题是一种经常在编程工作中被使用的技术,它为开发人员提供了构建强大的Web应用程序的能力。

在的应用范围内,开发人员可能会遇到各种各样的面试题。

本文将就一些常见的面试题进行探讨和解答。

一、什么是?是一种用于创建Web应用程序的开发框架。

它是由Microsoft开发的,基于.NET平台,并且与C#语言密切相关。

采用了面向对象编程(OOP)的概念和模型,为开发人员提供了一种简单而强大的方法来构建Web应用程序。

二、和ASP之间有何区别?和ASP的主要区别在于它们的开发模型和技术。

ASP是一种基于脚本的开发方式,而采用了面向对象的开发模型。

ASP使用VBScript或JScript等脚本语言,而使用编译语言,如C#、等。

也更加强大和灵活,提供了更高级的开发功能和性能优化。

三、什么是ViewState?ViewState是一种用于跨页面保持状态信息的技术。

它允许在两个请求之间存储和传输数据。

ViewState默认情况下将数据存储在隐藏的表单字段中,并在每个请求之间进行传输。

开发人员可以使用ViewState来保持页面上某个控件的状态,以便在页面回发时恢复控件的值。

四、什么是的生命周期?请解释每个阶段的作用。

的生命周期包括以下几个阶段:1. 初始化阶段(Init):在此阶段中,会初始化页面和控件。

开发人员可以在此阶段进行一些初始化设置和处理。

2. 加载阶段(Load):在此阶段,会加载页面的状态以及用户请求的数据。

此时,开发人员可以在此阶段处理用户的输入。

3. 验证阶段(Validate):在此阶段中,会验证页面和控件上的输入,并根据验证规则进行处理。

4. 回发数据处理阶段(PostBack Data Process):在此阶段中,会处理由用户操作引起的回发数据,并根据需要更新页面的状态。

5. 渲染阶段(Render):在此阶段,会生成并发送响应给客户端。

开发人员可以在此阶段对页面进行最后的修改。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

ASP.NET 页生命周期概述
常规页生命周期阶段
一般来说,页要经历下表概述的各个阶段。除了页生命周期阶段以外,还有在请求前后出现的应

用程序阶段,但是这些阶段并不特定于页。有关更多信息,请参见 ASP.NET 应用程序生命周期
概述。

阶段 说明

页请求 页请求发生在页生命周期开始之前。用户请求页时,ASP.NET 将
确定是否需要分析和编译页(从而开始页的生命周期),或者是
否可以在不运行页的情况下发送页的缓存版本以进行响应。

开始
在开始阶段,将设置页属性,如 Request 和 Response。在此阶

段,页还将确定请求是回发请求还是新请求,并设置 IsPostBack
属性。此外,在开始阶段期间,还将设置页的 UICulture 属性。

页初始化 页初始化期间,可以使用页中的控件,并将设置每个控件的
UniqueID 属性。此外,任何主题都将应用于页。如果当前请求
是回发请求,则回发数据尚未加载,并且控件属性值尚未还原为
视图状态中的值。

加载
加载期间,如果当前请求是回发请求,则将使用从视图状态和控

件状态恢复的信息加载控件属性。

验证
在验证期间,将调用所有验证程序控件的 Validate 方法,此方

法将设置各个验证程序控件和页的 IsValid 属性。

回发
事件
如果请求是回发请求,则将调用所有事件处理程序。
处理
呈现
在呈现期间,视图状态将被保存到页,然后页将调用每个控件,

以将其呈现的输出提供给页的 Response 属性的
OutputStream。

卸载
完全呈现页、将页发送至客户端并准备丢弃时,将调用卸载。此

时,将卸载页属性(如 Response 和 Request)并执行清理。

生命周期事件
在页生命周期的每个阶段中,页将引发可运行您自己的代码进行处理的事件。对于控件事件,通
过以声明方式使用属性(如 onclick)或以使用代码的方式,均可将事件处理程序绑定到事件。

页还支持自动事件连接,即,ASP.NET 将寻找具有特定名称的方法,并在引发特定事件时自动运
行这些方法。如果 @ Page 指令的 AutoEventWireup 属性设置为 true(或者如果未定义该属性,
因为默认情况下为 true),页事件将自动绑定至使用 Page_event 命名约定的方法,如
Page_Load 和 Page_Init。有关自动事件连接的更多信息,请参见 ASP.NET Web 服务器控件事
件模型。

下表列出了最常用的页生命周期事件。实际的事件比列出的事件要多。但是,它们不用于大多数
页处理方案。而是主要由 ASP.NET 网页上的服务器控件使用,以初始化和呈现它们本身。如果
要编写自己的 ASP.NET 服务器控件,则需要详细了解这些阶段。有关创建自定义控件的信息,
请参见开发自定义 ASP.NET 服务器控件。

页事件 典型使用

Page_PreInit

使用 IsPostBack 属性确定是否是第一次处理

该页。

创建或重新创建动态控件。

动态设置主控页。

动态设置 Theme 属性。

读取或设置配置文件属性值。
注意
如果请求是回发请求,则控件的值尚未从视图状态
还原。如果在此阶段设置控件属性,则其值可能会
在下一阶段被改写。

Page_Init  读取或初始化控件属性。
Page_Load  读取和更新控件属性。
Control events 执行特定于应用程序的处理:

如果页包含验证程序控件,请在执行任何处理
之前检查页和各个验证控件的 IsValid 属性。

处理特定事件,如 Button 控件的 Click 事
件。

Page_PreRender  对页的内容进行最后更改。
Page_Unload 执行最后的清理工作,可能包括:

关闭打开的文件和数据库连接。

完成日志记录或其他特定于请求的任务。
注意
在卸载阶段,页及其控件已被呈现,因此无法对响
应流做进一步更改。如果尝试调用方法(如
Response.Write 方法),则该页将引发异常。

其他的页生命周期注意事项
请注意有关页生命周期的以下附加信息:
 各个 ASP.NET 服务器控件都有自己的生命周期,该生命周期与页生命周期类似。例如,
在相应的页事件期间将调用控件的 Init 和 Load 方法。如果页上包含控件,则将首先调用
控件的 Init 方法,然后再调用页的 Init 方法。但是,将在调用控件的 Load 方法之前先
调用页的 Load 方法。
 通过处理控件的事件,可以自定义控件的外观或内容。例如,所有的控件都将引发 Init、
Load 和 Unload 事件,但是页开发人员通常不处理这些事件。而是通常处理特定于控件的
事件,如 Button 控件的 Click 事件和 ListBox 控件的 SelectedIndexChanged 事件。在
某些情况下,可能也需处理控件的 DataBinding 或 DataBound 事件。有关更多信息,请参
见各个控件的类参考主题以及开发自定义 ASP.NET 服务器控件。
 除了处理由页引发的事件以外,还可以重写页的基类中的方法。例如,可以重写页的
InitializeCulture 方法,以便动态设置区域性信息。注意,在使用 Page_event 语法创建
事件处理程序时,将隐式调用基实现,因此无需在方法中调用它。例如,无论是否创建
Page_Load 方法,始终都会调用页基类的 OnLoad 方法。但是,如果使用 override 关键字
(在 Visual Basic 中为 Overrides)重写页的 OnLoad 方法,则必须显式调用基方法。例
如,如果在页中重写 OnLoad 方法,则必须调用 base.Load(在 Visual Basic 中为
MyBase.Load)以运行基实现。

请参见

参考
在 ASP.NET 网页中验证用户输入

概念
ASP.NET Web 应用程序中的页和应用程序上下文
视图状态概述

其他资源
ASP.NET 页语法
ASP.NET 网页中的服务器事件处理

相关文档
最新文档