ASP.NET 是一个使用 HTML、CSS、JavaScript 和服务器脚本创建网页和网站的开发框架。 Show
ASP.NET 支持三种不同的开发模式:
Web Pages 教程如果您刚接触 ASP.NET ,建议从 Web Pages 开始学习。 Web Pages 是开发 ASP.NET 网站最简单的开发模式。 在我们的 Web Pages 教程中,您将学习如何使用 VB (Visual Basic) 或者 C# (C sharp) 最新的 Razor 服务器标记语法将 HTML、CSS、JavaScript 和服务器代码结合起来。 您也可以学习如何使用具有可编程的 Web Helpers(包括数据库、视频、图形、社交媒体等等)来扩展您的网页。 现在开始学习 ASP.NET Web Pages! MVC 教程MVC 是一种使用 MVC(Model View Controller 模型-视图-控制器)设计创建 Web 应用程序的模式。 如果您想要一个替代传统的 ASP.NET 的轻量级的开发模式,可以从 MVC 开始学习。 在我们的 MVC 教程中,您将学到如何使用集成了现有的所有 ASP.NET 特性(比如 Master Pages、 Security、Authentication 母版页、安全、验证)的轻量级的开发模式创建 Web 应用程序。 现在开始学习 ASP.NET MVC! Web Forms 教程Web Forms 是传统的基于事件驱动的 ASP.NET 模式。 多年来,开发者已经使用 ASP.NET Web Forms 创建了许多众所周知的大型网站。 如果您想学习在过去的 10 年中许多 Web 开发人员使用的设计模式,那么您可以从 Web Forms 开始学习。 现在开始学习 ASP.NET Web Forms! 谁适合阅读本教程?本教程适合于任何想要学习在微软 ASP.NET 平台上创建网站的人员,从业余站点到最新的、现代化的、完全商业化的网络。 即使您是刚接触 Web 编程,您也可以学习本教程,如果对 HTML 和 CSS 有基本的了解将会有助于本教程的学习。 如果您对脚本语言如 JavaScript 或者 VB (Visual Basic) 有基本的了解,那将会对学习本教程很有帮助。 您是否偏爱 VB 胜过 C# (C sharp) ?您是否想学习这两种语言?有个好消息:菜鸟教程提供的大多数代码实例都有这两种语言的版本。 如果您是一名有过 ASP.NET 开发经验的专业的 Web 开发人员,您仍然可以从本教程中学到很多东西,因为这些教程介绍了很多新的 ASP.NET 的概念,比如 HTML5、CSS3、JQuery 等等。 ASP.NET
ASP.NET是由微软在.NET
Framework框架中所提供,开发Web应用程序的类别库,封装在 ASP.NET可以运行在安装了.NET Framework的IIS服务器上,若要在非微软的平台上执行,则需要使用Mono平台[1],ASP.NET在2.0版本已经定型,在.NET Framework 3.5上则加上了许多功能,像是ASP.NET AJAX、ASP.NET MVC Framework、ASP.NET Dynamic Data与Microsoft Silverlight的服务器控件等。 很多人都把 ASP.NET 当做是一种编程语言,但它实际上只是一个由 .NET Framework 提供的一种开发平台 (development platform),并非编程语言。也可认为ASP.NET是.NET组件,任何.NET语言,例如C#,可以引用该组件,创建网页或Web服务。 为了因应云端化所诱发的多作业平台集成与开发能力,微软特别开发一个新一代的 ASP.NET,称为 ASP.NET vNext,并于 2014 年命名为 ASP.NET 5,但随后于 2016 年将它更名为 ASP.NET Core,由于架构上的差异颇大,因此未来 ASP.NET 与 ASP.NET Core 将是分别发展与维护,Windows 平台的 ASP.NET 4.6 以上版本仍维持 Windows Only,但 ASP.NET Core 则是具有跨平台 (Windows, Mac OSX 与 Linux) 的能力。 发展缘起[编辑]ASP.NET的前身ASP技术,是在IIS 2.0上首次推出(Windows NT 3.51),当时与 ADO 1.0 一起推出,在IIS 3.0(Windows NT 4.0)发扬光大,成为服务端应用程序的热门开发工具,微软还特别为它量身打造了Visual InterDev开发工具,在1994年到2000年之间,ASP技术已经成为微软推展Windows NT 4.0平台的关键技术之一,数以万计的ASP网站也是这个时候开始如雨后春笋般的出现在网络上。由于它的简单以及高度客制化的能力,也是它能迅速窜起的原因之一。 不过ASP的缺点也逐渐的浮现出来:
1997年时,微软开始针对ASP的缺点(尤其是意大利面型的程序开发方法)准备开始一个新项目来开发,当时ASP.NET的主要领导人斯科特·格思里刚从杜克大学毕业,他和IIS团队的Mark Anders经理一起合作两个月,开发出了下一代ASP技术的原型,这个原型在1997年的圣诞节时被发展出来,并给予一个名称:XSP[2],这个原型产品使用的是Java语言。不过它马上就被纳入当时还在开发中的CLR平台,Scott Guthrie事后也认为将这个技术移植到当时的CLR平台,确实有很大的风险(huge risk),但当时的XSP团队却是以CLR开发应用的第一个团队。 为了将XSP移植到CLR中,XSP团队将XSP的核心程序全部以C#语言重新撰写(在内部的项目代号是 "Project Cool",但是当时对公开场合是保密的),并且改名为ASP+,作为ASP技术的后继者,并且也会提供一个简单的移转方法给ASP开发人员。ASP+首次的Beta版本以及应用在PDC 2000中亮相,由Bill Gates发表Keynote(即关键技术的概览),由富士通公司展示使用COBOL语言撰写ASP+应用程序,并且宣布它可以使用Visual Basic.NET、C#、Perl与Python语言(后两者由ActiveState公司开发的互通工具支持)来开发。 在2000年第二季时,微软正式推动.NET策略,ASP+也顺理成章的改名为ASP.NET,经过四年的开发,第一个版本的ASP.NET在2002年1月5日亮相(和.NET Framework 1.0),Scott Guthrie也成为ASP.NET的产品经理(到现在已经开发了数个微软产品,像ASP.NET AJAX和Microsoft Silverlight)。 ASP.NET处理架构[编辑]ASP.NET 运行的架构分为几个阶段:
Web服务器的消息流动阶段[编辑]当装载(hosting) ASP.NET 的 Web 服务器接收到 HTTP 请求时,HTTP 聆听程序 (HTTP Listener,实际上是内核态的HTTP.SYS) 会将请求转交给 URL 指定的网站应用程序池中的工作者进程 (Worker Process)[3],ASP.NET 的工作者进程接收到这个请求之后,装载专用于处理ASP.NET页面的一个ISAPI扩展“aspnet_isapi.dll”,并将HTTP请求传给它。若是 IIS 5.0 时则是 aspnet_wp.exe。 aspnet_isapi.dll负责加载ASP.NET应用程序的运行环境CLR(IIS 7集成模式下,CLR是预加载的),每个ASP.NET应用程序都运行于自己的应用程序域(AppDomain)中。每个应用程序域都对应着一个ApplicationManager类的实例(通过AppManagerAppDomainFactory创建),负责管理运行在域中的ASP.NET应用程序(启动和停止一个ASP.NET应用程序、创建对象等)。ApplicationManager还会创建一个HostingEnvironment对象,提供了ASP.NET应用程序的一些管理信息(如ASP.NET应用程序的标识、虚拟目录与对应的物理目录等)。 应用程序域创建完成之后,创建 System.Web.Hosting 名字空间中的基于ISAPIRuntime的一个对象,调用其ProcessRequest()方法。在此方法中,根据传入的HTTP请求信息屏蔽了版本差异化后封装实例化了一个HttpWorkerRequest的对象并初始化一个HttpRuntime对象。调用HttpRuntime的ProcessRequestInternal方法。ProcessRequestInternal方法实例化一个HttpContext对象(其构造函数内部又实例化了在ASP.NET编程中非常重要的HttpRequest和HttpResponse对象)、通过HttpApplicationFactory获取HttpApplication对象实例。再调用HttpApplication对象的BeginProcessRequest方法启动整个HTTP请求的处理过程(即HTTP管线模式)。 System.Web.UI.Page类提供了“Requset”和“Response”属性来引用这两个对象,因此在ASP.NET网页中可以直接访问这两个对象。同样,System.Web.UI.Page类的Context属性引用HttpContext对象。 HttpRuntime类的ProcessRequest()方法除了创建HttpContext对象之外,还完成了另一个很重要的工作——向HttpApplicationFactory类的一个实例(它管理一个HttpApplication对象池)申请分配一个HttpApplication对象用于管理整个“HTTP请求处理管线(HTTP Pipeline)”中的各种事件的激发。在HttpApplication对象的InitModules()方法中创建HTTP模块(HTTP Module),通常在HTTP模块对象(实现IHttpModule接口)的Init()方法中响应HttpApplication对象所激发的特定事件。开发者可以创建基于IHttpHandler接口的对象,在Web.Config中插入特定的内容可以将自定义的HTTP模块加入到HTTP请求的处理流程中。 在IIS6和IIS7经典模式下,是用 Event+事件名称做key将所有事件的保存在HttpApplication的Events属性对象里,然后在BuildSteps里统一按照顺序组装。在IIS7集成模式下,是通过HttpModule名称+RequestNotification枚举值作为key将所有的事件保存在HttpApplication的ModuleContainers属性对象里,这个属性的类型是PipelineModuleStepContainer[]。 “HTTP请求处理管线(HTTP Pipeline)”的处理过程为:
具体的处理管线:
在 ASP.NET 内部的 HTTP 处理器有:
ASP.NET网页中的事件程序[编辑]当 HttpWorkerRequest 调用 ASP.NET 网页(System.Web.UI 名字空间的 Page 类别)的 Page.ProcessRequest() 方法时,它会依序的引发 Page 内的各个事件,并同时调用在 Page 中所有控件的相关事件,其引发顺序为[4]: 启动阶段:设置页面基本属性,如 Request 和 Response。在此阶段,页面还将确定请求是回发请求还是新请求,并设置 IsPostBack 属性。
如果 HttpWorkerRequest 调用的是实现 IHttpHandler 接口的 HTTP 处理函数 时,它只会调用 IHttpHandler.ProcessRequest() 方法,由它来处理程序的输出,不像 Page.ProcessRequest() 会处理事件顺序,因此 HTTP Handler 很适合轻量级的资料处理,像是输出文件资料流或是图片资料流等。 ASP.NET的事件模型[编辑]ASP.NET 的原始设计构想,就是要让开发人员能够像 VB 开发工具那样,可以使用事件驱动式程序开发模式 (Event-Driven Programming Model) 的方法来开发网页与应用程序,若要以ASP技术来做到这件事的话,就必须要使用大量的辅助信息,像是查询字符串或是窗体字段资料来识别与判断对象的来源、事件流向以及调用的函数等等,需要撰写的代码量相当的多,但 ASP.NET 很巧妙利用窗体字段和JavaScript脚本把事件的传递模型隐藏起来了。 ASP.NET 的事件模型是由 为确保控件的事件能够确实被引发,让事件驱动能够被执行,因此控件事件引发命令时需要的参数,是交由 JavaScript 脚本在客户端引发时,填入另一个 Hidden Field(ID 为
ASP.NET的来回模式[编辑]在 ASP.NET 运行的时候,经常会有网页的来回动作 (round-trip),在 ASP.NET 中称为 PostBack,在传统的 ASP 技术上,判断网页的来回是需要由开发人员自行撰写,到了 ASP.NET 时,开发人员可以用 Page.IsPostBack 机能来判断是否为第一次执行(当 ASP.NET 发现 HTTP POST 要求的资料是空值时),它可以保证 ASP.NET 的控件事件只会执行一次,但是它有个缺点(基于 HTTP POST 本身的缺陷),就是若用户使用浏览器的刷新功能(按 F5 或刷新的按钮)刷新网页时,最后一次执行的事件会再被执行一次,若要避免这个状况,必须要强迫浏览器清空缓存才可以。 ASP.NET 2.0 中有新增三个来回模式:
来回模式不仅是 ASP.NET 运作时的核心,它也是 ASP.NET 应用程序的一个主要缺点,尤其是在设计复杂度高的页面时,在网页中隐藏的 ViewState 的大小会相当大,而在每次的来回动作中,都会发送 ViewState 在内的窗体信息,大量的 ViewState 会使得发送的时间拉长,而且每次来回动作都会让整个网页被刷新,而出现闪烁的情况(就算在本地端也一样),但在AJAX技术尚未成熟时,只能够忍受这种因底层限制所带来的问题,在ASP.NET AJAX技术发展出来后,透过UpdatePanel成功的缓解了这个问题(但 ViewState 发送的问题仍然未根本的解决,必须要使用像 Page Method 这样的方式才能彻底的解决)。 绘制技术[编辑]熟悉 ASP 技术的人都知道,代码都是混在 HTML 标签之间,以输出预期需要的 HTML 指令,这个技术在 ASP.NET 中,由各控件的绘制 (Render) 机制包装起来了,绘制机制装载了 HtmlTextWriter 对象,由它来产生 HTML 指令,它会输出至 HttpContext 的 Response 输出资料流中(即 ASP 技术的 Response.Write()),下列代码为绘制技术的示例: [System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand, Name="FullTrust")] protected override void Render(HtmlTextWriter output) { if ( (HasControls()) && (Controls[0] is LiteralControl) ) { output.Write("<H2>Your Message: " + ((LiteralControl) Controls[0]).Text + "</H2>"); } } 为了让控件的输出有层次结构性,ASP.NET 开发了一个可以层次结构化输出控件 HTML 指令的方式,称为控件树 (Control Tree),借由控件树,可以让各个控件的输出可以层次结构化,不论是否是收纳型控件,还是一般型的控件,都可以按照控件的顺序来输出。 状态管理[编辑]状态管理 (state management) 在Web应用程序中,一向是很重要的课题,良好的状态管理可以帮助开发人员发展出具有状态持续能力的应用程序(像是工作流程型应用程序或是电子商务应用程序),但状态管理功能会视应用程序的部署状态以及信息的共享程度来选择,在 ASP.NET 中,分为服务端状态管理以及客户端状态管理,客户端状态管理为ViewState以及Cookies,服务端状态管理则是Session与Application对象。它们的差异点在于:
应用程序层级对象[编辑]Application 对象会在应用程序的 Application_OnStart 事件中初始化,并使用名称来识别资料(它是一个 NameObjectCollectionBase 集合的实现品),它会存储在应用程序的范围内,所有的连线(用户)都可以使用,属于共享型的存储体,适合存储所有用户都可使用的资料,在多人使用的情况下,可以适当的使用 Lock/Unlock 的机制来确保应用程序状态的更新。 Application.Lock(); Application["PageRequestCount"] = ((int)Application["PageRequestCount"])+1; Application.UnLock(); 连线层级对象[编辑]连线层级的对象是 Session,以浏览器的执行个体为识别单位,资料依浏览器的执行个体来存储,在浏览器的执行个体第一次连到应用程序时,ASP.NET会设置一个Session ID,并且使用它来识别 Session,每一个 Session 都是 ICollection 与 IEnumerate 的实现,用 key 来识别资料值,并且具有时间的限制 (timeout),若超出时限时服务器会自动清理掉,默认的 Session 时限为 20 分钟。Session ID 的算法是由 RNGCryptoServiceProvider(密码编译随机数产生器提供者)产生,并编码成一个 Session ID 字符串(例如 anf4vuup3xiq0arjlqla2l55 这样的字符串)存储在服务器中,用以识别不同的 Session 个体。 为因应不同的客户端,ASP.NET 设计了不同的 Session ID 存放机制,像是旧式的浏览器或是移动客户端这种不支持本地存储cookie的设备时,ASP.NET 可以直接在 URL 中加上 Session ID 的识别,像是 Session ID 的产生方法可以由程序开发人员自定义,借由改写 SessionIDManager 的 CreateSessionID() 方法来自定义。 using System; using System.Configuration; using System.Web.Configuration; using System.Web; using System.Web.SessionState; namespace Samples.AspNet.Session { public class GuidSessionIDManager : SessionIDManager { public override string CreateSessionID(HttpContext context) { return Guid.NewGuid().ToString(); } public override bool Validate(string id) { try { Guid testGuid = new Guid(id); if (id == testGuid.ToString()) return true; } catch { } return false; } } } 跨机器状态管理[编辑]状态管理在单一服务器上,可以存储在服务器的存储器中,但若是在大型网站中,使用许多的 Web 服务器来实行负载平衡(Load Balancing)处理时,会有状态存储在哪个位置的问题,因此需要有一个可以在每个 Web 服务器之间做状态存储的介质,像是独立的服务器或是数据库等等。在 ASP.NET 中支持了四种状态存储的介质[5]:
部件[编辑]ASP.NET 是开发 Web 应用程序的基础架构 (framework),除了它内部的运作方法外,对外也显露了许多的开发支持,让开发人员可以利用它来发展出许多强大的 Web 应用程序解决方案。 基础部件[编辑]网页[编辑]ASP.NET 最基础的底层为网页 (Page),网页由 在网页中也可以使用代码,以类似于ASP时代的撰写方式来开发,此种开发方式称为 inline code,在 ASP.NET 的程序开发模式中,inline code ,要放在 <%@ Page Language="C#" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <script runat="server"> protected void Page_Load(object sender, EventArgs e) { Label1.Text = DateTime.Now.ToLongDateString(); } </script> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title>Sample page</title> </head> <body> <form id="form1" runat="server"> <div> The current time is: <asp:Label runat="server" id="Label1" /> </div> </form> </body> </html> 另一种模式则是将代码和网页分离,这种模式称为代码后置 (Code-Behind),这个方法可以将代码独立到一个文件中,网页可以保持较干净的状态,让维护网页程序的复杂度降低很多,在网页的提示指令 (directive) 中,可以设置代码后置的参数,像是 Inherit、CodeFile、Class 等参数。 <%@ Page Language="C#" CodeFile="SampleCodeBehind.aspx.cs" Inherits="Website.SampleCodeBehind" AutoEventWireup="true" %> 而一个典型的代码后置例子为: using System; namespace Website { public partial class SampleCodeBehind : System.Web.UI.Page { protected override void Page_Load(EventArgs e) { base.OnLoad(e); } } } 使用代码后置模式的设置时,可以让 ASP.NET 执行引擎在加载网页时,由代码后置参数获取对应的类别信息,藉以使用 Reflection 的方式来执行后置的代码。 ASP.NET 可以支持HTML和XHTML两种网页内容,但在Visual Studio.NET中,默认是使用 HTML,但在Visual Studio 2005以后的版本,则一律都改用XHTML格式。 控件[编辑]ASP.NET 的内置控件分为两种:
除了内置的控件之外,ASP.NET 也提供了可以自定义的控件架构,并且支持两种控件开发方法:
脚本[编辑]ASP.NET 的 Web 控件有时会包装一些客户端脚本 (client-side scripting),在控件被绘制时输出到客户端,这些脚本多数被包装在 DLL 的资源档中,并由 ScriptResource.axd 处理函数来输出,开发人员也可以利用 ClientScriptManager(Page.ClientScript 属性)中的方法来添加脚本到网页程序中,常用的方法有:
基本对象[编辑]以往在 ASP 中常被使用的五大基本对象,在 ASP.NET 中仍然持续被支持,但它们都换了一个身份来提供:
导览部件[编辑]导览部件 (navigation controls)[6] 是在 ASP.NET 2.0 中才出现的功能,包含:
应用程序服务[编辑]应用程序服务 (application services) 是在 ASP.NET 2.0 中才开始提供,它以 Provider-based Pattern 为主,实现出数个网站的常用服务,包含会员服务 (Membership Service)[7]、角色服务 (role service)[8]与配置文件服务 (profile service)[9] 等。 会员服务由 Membership 以及其资料提供者 MembershipProvider 构成,应用程序使用 Membership 所显露的方法来操作,它会将要求转送给指定的 MembershipProvider 实现来处理,ASP.NET 目前支持来自于数据库的 SqlMembershipProvider(支持 SQL Server)以及来自于活动目录的 ActiveDirectoryMembershipProvider,开发人员也可以自行由 MembershipProvider 继承来实现自定义的会员服务资料提供者。 角色服务与会员服务类似,由 Role 以及其资料提供者 RoleProvider 构成,应用程序使用 Role 所显露的方法操作,由 RoleProvider 实现提供资料服务,目前内置的 RoleProvider 有来自 活动目录 或 XML 文件的 AuthorizationStoreRoleProvider,由 SQL Server 供应资料的 SqlRoleProvider,以及支持 Windows 角色的 WindowsTokenRoleProvider 三种,开发人员可自行实现 RoleProvider 的方法以发展出自定义的角色服务提供者。 配置文件服务是一个特殊的服务,它结合了 .NET Framework 的 CodeDOM 开发模式,以及 System.Web.Profile 名字空间的 ProfileBase、ProfileInfo 与 ProfileManager 等类别,组合出完整的配置文件支持,其数据源也是以 Provider-based Pattern 为主,由 ProfileProvider 提供,ASP.NET 内置由 SQL Server 数据库创建的 SqlProfileProvider,其字段系由开发人员在 ASP.NET 配置文件中自行定义,再由 ASP.NET 动态产生强类型的字段属性。 配置文件服务也是作为 ASP.NET 2.0 的网页组件 (Web Part Framework) 所需要的配置文件存储支持[10],Web Part Framework 可以让开发人员可以开发出具备个性化能力 (Personalization) 的网页配置方案,让用户可以用自行新增与拖放的方式来设计自己的网页布置,所需要的设置存储即由配置文件服务处理。 另一个需要和应用程序服务配合使用的功能为 Web 事件架构 (Web Event Framework)[11],它需要由应用程序服务提供数据结构,它也有 Provider-based Pattern,并可以支持数种的事件资料提供者。 延展性支持[编辑]除了 ASP.NET 网页以外,.NET Framework 还提供了两种可以由开发人员自行发展处理模型的模块,一种是HTTP Handler,另一种则是HTTP Module[12]。 HTTP Handler(扩展名为 .ashx)由 System.Web.IHttpHandler 接口定义了必要的方法(可支持异步的 HTTP Handler 称为 HTTP Async Handler,由 System.Web.IHttpAsyncHandler 接口定义),其中最重要的方法是 ProcessRequest() 方法,开发人员必须要实现这个方法,才能够让 HTTP Handler 有作用,它也可以透过 ASP.NET 的配置设置,让 HTTP Handler 可以处理特定的扩展名,它可以被视为 .NET Framework 中的 ISAPI Extensions 实现方法。 HTTP Module 则是由 System.Web.IHttpModule 接口定义,它可以在整个网页生命周期中被调用多次,并实际处理由 HttpApplication 所引发的事件,开发人员需要实现 IHttpModule.Init() 方法,以及处理 HttpApplication 事件需要的代码。它可被视为 .NET Framework 中的 ISAPI Filter 实现方法。 一致性与多样性接口的支持 [编辑]ASP.NET
在一开始的时候是缺乏模板引擎 (template engine) 的,其主因是.NET Framework本身是面向对象,且需要用继承的方式才能够延伸功能,大多数的开发人员都是由 System.Web.UI.Page 继承并定义出新的基类,并撰写要绘制 HTML 的方法,以及在他们的应用程序中修改以继承该类别,然而这个方法可能会被用在网站的很多地方,因而会大大的提升混合代码与标记的复杂度,这个方法也只能在执行期才能够以可视化的方式测试,无法在设计时期可视化,其他的开发人员总是使用原有的 ASP 方法(即 在 ASP.NET 2.0 中,推出了母板页面 (master page)的概念[13],它可以让开发人员先行定义外观版型 (*.master),再使用它来应用实际执行的网页,网页与主版页面之间以 ContentPlaceHolder 的 ID 做链接,以应用正确的内容到保留区(即由 ContentPlaceHolder 包住的区域)中,开发人员也可以定义在保留区没有应用时需要显示的默认内容。在 ASP.NET 3.5 中更进一步的支持设计时期的嵌套主版页面 (nested master pages),以及把网页的 HEAD 区块纳入 ContentPlaceHolder 的范围。 与主版页面相关的,还有主题(Theme)以及面板(skin)技术[14],这两个技术允许开发人员或设计人员自行定义网页的样式设置以及应用的样式支持,每个主题中可以包含数个面板档,这些面板档决定了控件要输出时应用的样式,开发人员则可以利用主题来决定不同的外观要使用的样式。 ASP.NET 也允许在应用程序中动态的变更主版页面与主题,但必须要在页面的 PreInit 事件例程设置。 void Page_PreInit(Object sender, EventArgs e) { Page.MasterPageFile = "~/NewMaster.master"; Page.Theme = "MyTheme"; } 编译模型[编辑]ASP.NET 在 1.x 时,使用的是组件为主的编译方式,一个网页只会产生一个组件,这个方式最大的优点,就是可以自由定义名字空间,且在部署应用程序时会比较方便,但由于 ASP.NET 1.x 所处的时代,如果网站是有许多代码的情况下(即 DLL 档很大),加载的速度会变慢,且占用存储器的量会很多,当时的存储器价格也尚未降到现在的水准。因此在 ASP.NET 2.0 开始,另外提供了一个预先编译(Pre-compilation) 的编译模型,这个编译方法会将每个网页都各自编译成一个组件,其文件名称会是 App_[随机数字符串].dll 命名,在编译时期由 ASP.NET Pre-compilation 工具(aspnet_compiler.exe)给定,优点是可以不必加载过量的代码到存储器中,但缺点则是无法自定义名字空间,而且在更新时必须要更新所有的 DLL 档以及网页等,否则会造成名称不一致,让 DLL 无法被加载的问题。 早期 ASP.NET 2.0 仅提供预先编译模式,让它的缺点很快的被暴露出来,因此微软也为 ASP.NET 2.0 开发了沿用 ASP.NET 1.x 的编译模型的工具:Web Application Project,在 Visual Studio 2008 中开始内置,至此,ASP.NET 支持两种编译模式的架构抵定。 安全性支持[编辑]ASP.NET 的安全性支持分为验证 (Authentication)与授权 (Authorization)两个部分。 验证[编辑]ASP.NET 的验证方式有三种[15]:
授权[编辑]ASP.NET 的授权方式有两种[16]:
一个 URL 授权的设置示例如下: <authorization> <allow users="Kim"/> <allow roles="Admins"/> <deny users="John"/> <deny users="?"/> </authorization> Web Service支持[编辑]ASP.NET 1.0 开始支持 Web Service 的开发,是微软在原生平台上支持 Web Service 发展的第一个实现品,但它却不是微软的第一个 Web Service 开发工具实现品[17],.NET Framework 中提供了一个 WSDL.exe,可以连接 Web Service 下载WSDL定义档,并产生一个 Proxy Class 的源代码,供客户端应用程序使用,若是使用 Visual Studio 开发的话,这个动作会由“加入 Web 参考”的动作在背后处理掉。 ASP.NET Web Service 的发展只是平台的基础,微软在 Web Service 的开发上提供持续的支持,尤其是在 WS-I (Web Service Interoperability) 组织成立后,为符合 WS-I 的 Web Service 标准,微软开发了强化 Web Service 的增强包 Web Service Enhancement (WSE),最新版本为 3.0 版(搭配 ASP.NET 2.0),可支持许多 WS-I 的标准。 由于 Windows Communication Foundation 的推出,微软将 Web Service 的发展重心移到 WCF 上,原有的 ASP.NET Web Service 即给定了一个名称:ASMX Web Service。 扩展[编辑]ASP.NET 在 2.0 版时,功能已大致底定,成为 Web 应用程序的基础架构,微软开始在 ASP.NET 2.0 上开发扩展的功能,包括 AJAX 的支持、MVC架构的支持以及更容易开发出数据库应用的架构。 ASP.NET AJAX[编辑]ASP.NET AJAX 是微软发展的 AJAX Framework,让 ASP.NET 的开发人员得以用很简单的方式就可以开发出支持 AJAX (AJAX-enabled) 的应用程序,包含客户端脚本的支持,以及服务端的链接等等。 ASP.NET MVC Framework[编辑]ASP.NET MVC Framework 是微软基于 MVC (Model-View-Controller) 架构所开发的架构,让应用程序各个模型可以在 MVC 架构下运行。
ASP.NET MVC Framework 也支持以测试驱动的开发模式 (Test-Driven Development)。 ASP.NET Dynamic Data Framework[编辑]ASP.NET Dynamic Data Framework 是微软在 ASP.NET 3.5 中开发的一组类别库,封装在 System.Web.DynamicData 名字空间中,并且配合 ASP.NET Routing Model(网页绕送功能)让开发人员可以很简单的开发出基于 LINQ to SQL 或是 ADO.NET Entity Framework 资料模型的数据库应用程序。 ASP.NET Routing[编辑]ASP.NET Routing Model(官方译名为 ASP.NET 路由)是一个基于REST规格下的 URL 对应机制,开发人员可以在服务端设置 URL 的格式,用户可以用由开发人员定义的 URL 格式浏览网页,ASP.NET 会自动将 URL 转换成为内部的 URL 格式,虽然它和 URL Rewriting 很像,但微软认为 ASP.NET Routing 不是 URL Rewriting[18]。 Silverlight[编辑]Silverlight 是微软的新一代RIA技术,ASP.NET 3.5 Service Pack 1 (SP1) 中加入了对 Silverlight 2.0 的 ASP.NET 服务端支持,包含:
开发工具[编辑]目前已有数个工具可支持 ASP.NET 应用程序的开发。
版本[编辑]在一台电脑上,查看Windows注册表的 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full 其Version节点显示的就是所安装的ASP.NET的版本号。
参见[编辑]
参考资料[编辑]
外部链接[编辑]
|