ASP.NET源代码论文（精选7篇）
ASP.NET源代码论文 篇1
摘要：本文基于源代码,探讨了客户端请求如何从非托管环境被传递到.NET CLR的托管环境,揭示了HttpRuntime在ASP.NET HTTPRuntime中的功能和作用,论述了HttpApplication管线的设计模式,并对事件驱动的截取过滤器模式中执行步的创建与执行进行了详细的探讨和描述。
关键词：ASP.NET,HTTPRuntime,设计模式
0 引言
ASP.NET是灵活的、可扩展的服务器端HTTP编程的框架,也是一个复杂的使用托管代码来处理Web请求的引擎。而HTTP管道是ASP.NET的核心基础架构,由一连串的托管对象组成[1],客户端关于ASP.NET文件的HTTP请求正是在这个管道中完成处理,最终生成HTML文本并返回给客户端。因此,对HTTP管道的深入了解,有助于构建功能更强,运行更安全的ASP.NET应用程序。基于源代码,本文揭示ASP.NET HTTP Runtime的诸多细节,同时须指出的是本文对HTTP管道的阐述均基于IIS6.0和ASP.NET2.0。
1 HTTP管道之前
当第一个关于ASP.NET文件的HTTP请求到达IIS时,此请求被内核模式下的HTTP.SYS所接收,然后被转发给工作者进程(w3wp.exe)处理,工作者进程接着加载aspnet_isapi.dll,并将该请求传递给它。接下来,aspnet_isapi.dll装载和初始化.NET CLR,同时实例化AppManagerAppDomainFactory对象[2],并以COM方式调用AppManagerAppDomainFactory.Create方法,该方法创建应用程序域(AppDomain)对象和ISAPIRuntime对象。
在.NET的框架类库中,IISAPIRuntime[3]是从ISAPI扩展到ASP NET的一个预定的接口[4]。其定义如下:
从该接口声明时使用的属性InterfaceTypeAttribute(ComInterfaceType.InterfaceIsIUnknown)可以看到:这个接口是作为IUnknown派生接口向COM公开的,这就使得aspnet_isapi.dll可以以早期绑定方式调用此接口。类ISAPIRuntime实现了IISAPIRuntime接口,而对HTTP请求的处理就始于aspnet_isapi.dll以COM方式调用ISAPIRuntime对象的ProcessRequest方法[5],该方法的签名如下:
public int ProcessRequest(IntPtr ecb,int i WRType)
其中,参数ecb是指向非托管的ISAPI ECB(即:ISAPI Extention Control Block)的指针,而ISAPI ECB具有访问完整的ISAPI接口的能力,ISAPI的这些接口可以用来检索HTTP请求数据和将响应发送回IIS。可见,当aspnet_isapi.dll调用该方法时就以一个IntPtr结构传入了自己的ISAPI ECB地址。
使用.NET Reflector查看ISAPIRuntime.ProcessRequest方法的源代码,可知在该方法中将调用ISAPIWorkerRequest类的静态方法CreateWorkerRequest,同时传入指向ISAPI ECB的指针,该方法会产生一系列的函数调用,最终会生成一个ISAPIWorkerRequest的派生类对象wr。实质上,ISAPIWorkerRequest类对ISAPI ECB进行了封装,使得ASP.NET能用统一的方法来处理HTTP请求信息。接下来,ISAPIRuntime.ProcessRequest会调用HttpRuntime的ProcessRequest NoDemand方法,同时将生成的ISAPIWorkerRequest派生类对象wr传入该方法。由是,对客户端请求的处理便逐步展开。
2 HTTP管道
HTTP管道是由一连串的托管对象组成,这些对象前后相继地对ASP.NET相关的HTTP请求进行处理,最终生成HTML代码并通过ISAPI ecb返回给IIS。这些托管对象及其在管道中的先后顺序,可以用以下类图表示。
这里选取管道中关键的两个类:HttpRuntime和HttpApplication为代表,对这两个类做一深入的解析。
2.1 HttpRuntime
HttpRuntime对象为应用程序提供一组ASP.NET运行时服务,是ASP.NET的HTTP管道的入口[6],对HttpRuntime的ProcessRequestNoDemand方法的调用将HTTP请求推入了ASP.NET的HTTP管道。HttpRuntime类的ProcessRequest NoDemand会产生一系列的函数调用,最终会调用该类的私有方法ProcessRequestInternal[7]。
在HttpRuntime.ProcessRequestInternal方法内首先将wr作为HttpContext的构造函数参数创建了HttpContext对象context[7]。使用.NET Reflector查看HttpContext构造函数源代码,存在语句this.Init(new HttpRequest(wr,this),new HttpResponse(wr,this))和this._response.InitResponseWriter(),前一语句以wr为参数创建了HttpRequest、HttpResponse对象,后一语句以HttpResponse对象为参数创建HttpWriter对象。因此,可以看出HttpContext、HttpRequest、HttpResponse、HttpWriter均是建立在wr之上,而wr是ISAPIWorkerRequest类的实例,封装了ISAPI ECB,所以HttpContext、HttpRequest、HttpResponse、HttpWriter实质上可以看成是对ISAPI ECB更高一层的托管环境封装器。
在接下来的HttpRuntime.ProcessRequestInternal方法内,会将对象context作为参数传递给HttpApplicationFactory的GetApplicationInstance[8]方法,该方法会对应用程序工厂(HttpApplicationFactory)作一些初始化的工作,包括:获取global.asax文件的路径,编译asp.net应用程序以及设置文件内容修改的监视器等,在编译asp.net应用程序时会创建HttpApplicationState对象。最后调用GetNormalApplicationInstance[8]方法从该应用程序工厂的栈_freeList中弹出一个HttpApplication对象,或创建一个HttpApplication对象。需指出的是HttpApplication对象的创建是在GetNormalApplicationInstance方法中通过调用HttpRuntime.CreateNonPublicInstance方法来实现的,可见HttpApplication对象的创建也是由HttpRuntime来完成的。
事实上,不仅HttpApplication对象,连HttpModule对象也是由HttpRuntime的相同方法来完成的。
在获取了HttpApplication对象,并完成对它的初始化工作以后,HttpRuntime.ProcessRequestInternal方法将调用HttpApplication.BeginProcessRequest方法,该方法的执行将启动应用程序管线,触发一系列的管线事件,而对HTTP请求进行处理的主要工作正是在这个应用程序管线中完成的。
通过以上的分析,可以看到HttpRuntime不仅是ASP.NET的HTTP管道的入口,而且也是HTTP管道的关键所在,它直接或间接地创建了管道中的诸多核心对象,包括:HttpContext、HttpRequest、HttpResponse、HttpWriter、HttpApplication以及HttpModule等等,并为处理客户端请求提供诸多的服务,如:启动应用程序管线来处理客户请求。总之,HttpRuntime为应用程序提供一组ASP.NET运行时服务。
2.2 HttpApplication
管线的设计模式在得到一个HttpApplication对象后,对HTTP请求的处理被移交给了这个对象。HttpApplication实质上是一个事件控制器,包含了一系列的前后相继发生的事件,每一个事件都是一个多播委托,每一个多播委托都具有0个或多个的该事件的处理方法。这些事件处理方法或者在HttpModule中定义,或者在Global.asax文件中定义,并在HttpApplication初始化过程中,通过调用HttpApplication.InitModulesCommon()[9]和HttpApplication.HookupEventHandlersFor ApplicationAndModules(handlers)[9]方法将这些事件处理方法挂接到相应的HttpApplication事件上。当这些事件依次触发的时候,挂接在每一个事件上的事件处理方法也被依次一一触发,而客户的请求在这样的一系列顺序执行的事件处理方法中不断的被截取和处理,上一个事件处理方法对客户请求的处理结果成为下一个事件处理方法的输入—HttpApplication对象处理客户请求的整个过程犹如了一个加工管线:客户请求从管线的入口进入,从管线的出口输出,得到处理的结果(即:HTML文本),而这个管线中的每一个加工环节就是一个事件处理方法。ASP.NET运行时对客户请求的这种处理模型是截取过滤器模式的一种变体:事件驱动的截取过滤器模式[10](event-driven Intercepting Filter pattern)。
但在HttpApplication管线中还包含了非事件性质的处理过程,如:对请求进行验证,以确认是否包含潜在恶意代码;对用户请求的URL进行映射;与用户请求资源相对应的处理程序的创建和执行以及HttpApplication管线最后的收尾工作等,这些处理环节都没有相应的管线事件来引发。为了给程序的调用方提供统一的调用接口,ASP.NET运行时对事件处理过程和非事件处理过程进行抽象,定义了被称为“执行步”的HttpApplication内部接口—IExecutionStep,每一个挂接到管线事件的处理方法和这些非事件处理过程都被描述为一个实现了该接口的执行步的对象。IExecutionStep接口定义如下:
每一种执行步都是HttpApplication的内部类,且都实现了该接口中的Execute()方法,以完成对HTTP请求的相应处理,对于涉及事件的执行步,在Execute()方法中还会通过委托来调用相应的事件处理方法。在HttpApplication管线中使用到的执行步的类型和功能如下:
ValidatePathExecutionStep:用于请求验证,以确认是否包含潜在恶意代码;
HttpApplication管线分为创建和执行两个部分。创建HttpApplication管线就是构建管线中的各个执行步,这是通过在HttpApplication.InitInternal()方法中调用内部类ApplicationStep Manager的BuildSteps方法实现的[9]。所有构建好的执行步被放到了HttpApplication的_execSteps字段,该字段实质上是一个ArrayList的对象。而启动HttpApplication管线来处理HTTP请求是在HttpRuntime的ProcessRequestInternal方法中调用HttpApplication.BeginProcessRequest方法来实现的:该方法会接着调用HttpApplication.ResumeSteps,HttpApplication.ResumeSteps又会调用ApplicationStepManager.ResumeSteps。在方法ApplicationStepManager.ResumeSteps[9]中会遍历执行保存在_execSteps字段中的所有执行步:对于字段_execSteps中的每一个执行步会调用方法HttpApplication.ExecuteStep[8],并在该方法中调用相应执行步的Execute方法。这样,HttpApplication管线中的每一个执行步都将被顺序执行,每一个事件的所有处理方法因此也将被依次的触发。
HttpApplication管线的Event-driven Intercepting Filter pattern中执行步的构建和触发过程如下图所示。
3 结束语
本文基于源代码,探讨了客户端请求如何从非托管环境的IIS被传递到.NET的托管环境,揭示了HttpRuntime在ASP.NET HTTP Runtime中的功能和作用,论述了HttpApplication管线的设计模式,并对构成管线的执行步的创建与执行进行了详细的探讨和描述。
参考文献
[1]Dino Esposito.The ASP.NET HTTP Runtime[EB/OL].http://msdn.microsoft.com/en-us/library/aa479328.aspx,2003-7.
[2]Simone Busoli.ASP.NET Internals-The bridge between ISAPI andApplication Domains[EB/OL].http://dotnetslackers.com/articles/iis/ASPNETInternalsIISAndTheProcessModel2.aspx,2007-6.
[3]IISAPIRuntime接口[EB/OL].ms-help://MS.MSDNQTR.v80.chs/MS.MSDN.v80/MS.NETDEVFX.v20.chs/cpref12/html/T_System_Web_Hosting_IISAPIRuntime.htm.
[4]Rick Strahl.A low-level Look at the ASP.NET Architecture[EB/OL].http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp.
[5]ISAPIRuntime.ProcessRequest方法[EB/OL].ms-help://MS.MSDNQTR.v80.chs/MS.MSDN.v80/MS.NETDEVFX.v20.chs/cpref12/html/M_System_Web_Hosting_ISAPIRuntime_ProcessRequest_1_1968a7bf.htm.
[6]HttpRuntime类[EB/OL].ms-help://MS.MSDNQTR.v80.chs/MS.MSDN.v80/MS.NETDEVFX.v20.chs/cpref12/html/T_System_Web_HttpRuntime.htm.
[7]HttpRuntime.cs source code in C#.NET[EB/OL].http://reflector.web-tropy.com/default.aspx/Dotnetfx_Vista_SP2/Dotnetfx_Vista_SP2/8@0@50727@4016/DEVDIV/depot/DevDiv/releases/whidbey/NetFxQFE/ndp/fx/src/xsp/System/Web/HttpRuntime@cs/1/HttpRuntime@cs
[8]HttpApplicationFactory.cs source code in C#.NET[EB/OL].http://re-flector.webtropy.com/default.aspx/Dotnetfx_Vista_SP2/Dotnetfx_Vista_SP2/8@0@50727@4016/DEVDIV/depot/DevDiv/releases/whidbey/NetFxQFE/ndp/fx/src/xsp/System/Web/HttpApplicationFactory@cs/1/HttpApplicationFactory@cs.
[9]HttpApplication.cs source code in C#.NET[EB/OL].http://reflector.webtropy.com/default.aspx/Net/Net/3@5@50727@3053/DEVDIV/depot/DevDiv/releases/whidbey/netfxsp/ndp/fx/src/xsp/System/Web/HttpApplication@cs/10/HttpApplication@cs.
[10]Implementing Intercepting Filter in ASP.NET Using HTTP Module[EB/OL].http://msdn.microsoft.com/en-us/library/ff649096.aspx.
ASP.NET源代码论文 篇2
如果连续的开发几个软件项目,我们就会发现自己编写了许多重复功能的代码,当我们认识到这点,就会产生复用代码的想法。事实上很多开发团队都建立了自己的代码库和组建库以方便的将他们应用到新的项目中。代码复用是绝大多数程序员所期望的,也是面向对象的目标之一。
代码复用在软件开发中存在两个层次。第一个层次是,在设计一个新的软件功能或是开发一个新的项目时,复用已存在的软件模块。另一个层次是,程序员在开发一个软件模块时,模块的内部应尽可能地复用。我们这里的案例指的是前者。
2 WEB自定义控件的应用
ASP.NET为我们提供了一个简单的工具来编写可重用的代码—WEB自定义控件。WEB自定义控件提供了这样一种机制,它使得我们可以开发出能够非常容易的被ASP.NET页面使用或者重新利用的代码部件。下文所给出的自定义验证码控件是对这种代码复用技术的典型应用。
在我们的例子当中,我们将要建立一个验证码控件,用来验证用户输入。在很多网站,不管是大型还是小中型网站,在其登录页面都需要一个这样的控件来防止恶意破解密码、刷票、论坛灌水等,验证码还可以有效防止某个黑客对某一个特定注册用户用特定程序暴力破解方式进行不断的登陆尝试。
建立验证码复用程序的第一步是新建asp.net网站,第二步是为该站点添加新建项目,在新建的项目中建立两个类,第一个类为WEB用户控件类AuthCode,用来定义验证码的属性和样式。该类的核心代码如下:
在该新建项目中再新建一个类AuthCodeHttpHander,用来处理IHttpHandler,IRequiresSessionState接口。该类主要是完成验证码的绘制,的核心代码如下:
第三步,生成解决方案,之后,打开Web窗体,可以看到在工具箱上出现了一个新的组件,如图1所示。
就可以在任何页面直接使用该控件了。但是值得注意的是,该使用该控件时,需指明MySize属性的值,这个值是验证码的字符长度。还可以利用this.AuthCode1.GetValue()获得验证码的值。图2是该控件的使用效果。
3 结论
ASP.NET源代码论文 篇3
1.1 两层结构及其局限性
两层结构有如下特点:
数据库访问和用户类型判断逻辑放在一起实现。
用户界面层直接调用数据访问实现。
整个系统功能放在同一项目中实现。
传统的两层结构的特点是用户界面层直接与数据库进行交互, 还要进行业务规则、合法性校验等工作。两层结构软件模型如图1所示。
这种结构存在着很多局限性, 比如:一旦用户的需求发生变化, 应用程序都需要进行大量修改, 甚至需要重新开发, 给系统的维护和升级带来了极大的不便, 用户界面层直接访问数据库, 会带来很多安全隐患。为了克服两层结构的局限性提出了三层结构。
1.2 定义
所谓三层体系结构, 是在客户端与数据库之间加入了一个“中间层”, 也叫组件层。这里所说的三层体系, 不是指物理上的三层, 不是简单地放置三台机器就是三层体系结构, 也不仅仅有B/S应用才是三层体系结构, 三层是指逻辑上的三层, 即使这三个层放置到一台机器上。通用三层结构软件模型如图2所示。
中间层通常包括业务逻辑层、数据访问层和数据对象模型层。此时的三层结构软件模型如图3所示。
用户界面 (User Interface, 简称UI) , 也称表示层, 位于最上层, 用于显示和接收用户提交的数据, 为用户提供交互式的界面。表示层一般为Windows窗体应用程序或Web应用程序。
业务逻辑层是表示层和数据访问层之间沟通的桥梁, 主要负责数据的传递和处理。
数据访问层主要实现对数据的读取、保存和更新等操作。
数据对象模型层即业务实体层。主要用于表示数据存储的持久对象。在实际应用程序中的实体类是跟数据库中的表相对应的, 也就是说一个表会有一个对应的实体类。当然有些三层结构并不包含单独的数据对象模型层, 而将其功能分解到业务逻辑层和数据访问层之中。
在三层结构中, 表示层直接依赖于业务逻辑层;业务逻辑层直接依赖于数据访问层;数据访问层直接依赖于数据对象模型层。
1.3 优势
三层结构主要体现出对程序分而治之的思想:数据访问层只负责提供原始数据, 并不需要了解业务逻辑;业务逻辑层调用数据访问层提供的方法自定义一些业务逻辑, 对数据进行加工, 本身不需要了解数据访问层的实现;表示层直接调用业务逻辑提供的方法把数据呈现给用户。
三层结构的优点在于不必为了业务逻辑上的微小变化而迁至整个程序的修改, 只需要修改商业逻辑层中的一个函数或一个过程;增强了代码的可重用性;便于不同层次的开发人员之间的合作, 只要遵循一定的接口标准就可以进行并行开发了, 最终只要将各个部分拼接到一起构成最终的应用程序。
三层结构的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下, 客户端不直接与数据库进行交互, 而是通过COM/DCOM通信与中间层建立连接, 再经由中间层与数据库进行交互, 这样会大大提高系统的安全性。
三层结构的应用程序更能够适应企业级应用日益增长的复杂度和灵活性的要求, 并且通过软件分层的高内聚、低耦合的原则, 实现扩展、维护和重用的要求, 可以大大提高开发效率。
2 搭建ASP.NET的三层结构框架
ASP.NET可以使用.NET平台快速方便地搭建三层结构。ASP.NET革命性的变化是在网页中也使用基于事件的处理, 可以指定处理的后台代码文件, 可以使用C#、VB作为后台代码语言。.NET中可以方便地实现组件的装配, 后台代码通过命名控件可以方便地使用自己定义的组件。表示层放在Web窗体中, 业务逻辑层、数据访问层和数据对象模型层用类库来实现, 这样就很方便地实现了三层结构。其方法如下。
(1) 建一个数据库 (简单起见可建Access数据库) , 以备存取数据。
(2) 新建解决方案
打开VS 2008, 新建一个“空白解决方案”, 将其命名为“Three Layers”。
(3) 搭建表示层 (网站)
在“解决方案资源管理器”中, 新建一个网站, 其存放位置为解决方案文件夹下的My Web子文件夹。
(4) 搭建业务逻辑层 (类库)
在“解决方案资源管理器”中, 新建一个“类库”项目。填写项目的名称为“Business Logic Layer”, 该项目用于实现业务逻辑。
(5) 搭建数据访问层 (类库)
在“解决方案资源管理器”中, 新建一个“类库”项目。填写项目的名称为“Data Access Layer”, 该项目用于实现数据访问层。
(6) 搭建数据对象模型层 (类库)
在“解决方案资源管理器”中, 新建一个“类库”项目。填写项目的名称为“Models”, 该项目用于实现数据实体。至此, 已搭建了三层结构 (添加了4个项目) 。
(7) 添加各层之间的依赖 (引用)
此时, 虽然三层结构的基本框架已经搭建成功, 但是各层之间是独立的。只有添加依赖关系, 才能让它们相互协作。
1) 添加表示层对业务逻辑层、数据访问层和数据对象模型层的依赖。
2) 添加业务逻辑层对数据访问层和数据对象模型层的依赖。
3) 添加业数据访问层对数据对象模型层的依赖。
至此, 三层结构及各层之间的依赖关系创建完毕。
(8) 将表示层设置为启动项目
通过上述步骤, 就已经成功部署了ASP.NET的三层架构。表示层My Web网站放置用于显示的Web页面;事务逻辑层Business Logic Layer项目, 把所有的业务逻辑代码在该层实现;数据访问层Data Access Layer项目主要处理数据库的操作, 供事务逻辑层调用;数据对象模型层Models项目实现数据实体类, 供其他各层调用。只要在各个层中实现具体的类就可以成功实施三层结构的应用程序了。
3 应用举例
3.1 系统分析
本例的功能非常简单, 只是实现用户登录与注册的功能, 用户信息存放在数据库中, 旨在体现如何用ASP.NET实现三层结构。
表示层My Web网站放置用于显示的Web页面;事务逻辑层Business Logic Layer项目, 把所有的业务逻辑代码在该层实现;数据访问层Data Access Layer项目主要处理数据库的操作, 供事务逻辑层调用;数据对象模型层Models项目实现数据实体类, 供其他各层调用。
各层次之间的调用 (引用) 关系如表1所示。
3.2 创建框架
3.2.1 建立数据库
打开Access创建名为userinfo.mdb的数据库, 并为其创建一个名为t_User的表, 其结构如图4所示。
3.2.2 新建解决方案
打开VS 2008, 依次选择“文件”→“新建”→“项目”命令, 打开“新建项目”对话框中, 然后选择项目类型为“Visual Studio解决方案”, 选择模板为“空白解决方案”。然后填写解决方案的名称为“Three Layers”, 并指定保存位置, 如图5所示。单击“确定”按钮, 创建解决方案。
3.2.3 搭建表示层
(1) 在“解决方案资源管理器”中, 在解决方案名称上单击鼠标右键, 在弹出的快捷菜单中选择“添加”→“新建网站”命令。
(2) 在打开的“添加新网站”对话框中, 选择“ASP.NET网站”, 选择位置为“文件系统”, 并设置网站的路径, 如图6所示。
(3) 设计Default.aspx如图7所示。
(4) 添加一Web窗体, 将其命名为Welcome.aspx, 其设计视图如图8所示。
(5) 添加一Web窗体, 将其命名为Register.aspx, 其设计视图如图9所示。
(6) 将建好的userinfo.mdb拷贝到站点的App_Data文件夹下。
(7) 添加Global.asax, 在其Application_Start () 添加如下代码。
3.2.4搭建业务逻辑层 (类库)
在“解决方案资源管理器”中, 在解决方案名称上单击鼠标右键, 在弹出的快捷菜单中选择“添加”→“新建项目”命令, 打开“新建项目”对话框中, 然后选择项目类型为“Visual C#”, 选择模板为“类库”。填写项目的名称为“BusinessLogic Layer”, 该项目用于实现业务逻辑。此时项目的保存位置已经默认输入了, 是刚才创建空白解决方案时产生的路径, 如图10所示。
3.2.5 搭建数据访问层 (类库)
在“解决方案资源管理器”中, 在解决方案名称上单击鼠标右键, 在弹出的快捷菜单中选择“添加”→“新建项目”命令, 打开“新建项目”对话框中, 然后选择项目类型为“Visual C#”, 选择模板为“类库”。填写项目的名称为“Data Access Layer”, 该项目用于实现数据访问层。此时项目的保存位置已经默认输入了, 是刚才创建空白解决方案时产生的路径。
3.2.6 搭建数据对象模型层 (类库)
在“解决方案资源管理器”中, 在解决方案名称上单击鼠标右键, 在弹出的快捷菜单中选择“添加”→“新建项目”命令, 打开“新建项目”对话框中, 然后选择项目类型为“Visual C#”, 选择模板为“类库”。填写项目的名称为“Models”, 该项目用于实现数据访问层。此时项目的保存位置已经默认输入了, 是刚才创建空白解决方案时产生的路径。
至此, 已搭建了三层结构 (添加了4个项目) , 此时的解决方案如图11所示。
3.2.7 添加各层之间的引用 (依赖)
此时, 虽然三层结构的基本框架已经搭建成功, 但是各层之间是独立的。只有添加依赖关系, 才能让它们相互协作。
(1) 添加表示层对业务逻辑层、数据访问层和数据对象模型层的依赖。
在“解决方案资源管理器”中, 在表示层上单击鼠标右键, 在弹出的快捷菜单中选择“添加引用”命令, 打开“添加引用”对话框, 然后选择“项目”选项卡, 选中项目名称为“Business Logic Layer”的项目, 单击“确定”按钮, 如图12所示。
同样添加对Data Access Layer和Models的引用。
(2) 添加业务逻辑层对数据访问层和数据对象模型层的依赖。
在“解决方案资源管理器”中, 在业务逻辑层上单击鼠标右键, 在弹出的快捷菜单中选择“添加引用”命令, 打开“添加引用”对话框, 然后选择“项目”选项卡, 选中项目名称为“Data Access Layer”的项目, 单击“确定”按钮。
同样添加对Models的引用。
(3) 添加数据访问层对数据对象模型层的依赖。
至此, 三层结构及各层之间的依赖关系创建完毕。现在Three Layers解决方案资源管理器应该如图13所示。
3.2.8 将表示层设置为启动项目
运行程序前, 还需设置启动项目。在“解决方案资源管理器”中的表示层上单击鼠标右键, 在弹出的快捷菜单中选择“设为启动项目”命令, 将表示层设置为启动项目。
将表示层设置为启动项目后, 表示层 (站点) 自动创建了Bin文件夹, 该文件夹下生成了:Business Logic Layer.dll、Business Logic Layer.pdb、Data Access Layer.dll、Data Access Layer.pdb、Models.dll和Models.pdb等6个文件, 如图14所示。
ASP.NET源代码论文 篇4
ASP和ASP.NET是Web开发领域比较流行的动态Web开发技术。ASP是Active Server Page的缩写, 即活动服务器页面, 是一个Web服务器端的开发环境, 利用它可以结合HTML网页、ASP指令和Active X元件建立和执行动态的、互动的、高性能的Web服务应用程序;ASP.NET并不是ASP的简单升级, 而是全新一代的动态网页实现系统, 它是微软发展的新体系结构.NET的一部分, 是ASP和.NET技术的结合。ASP.NET提供基于组件、事件驱动的可编程网络表单, 大大简化了编程, 还可以用于建立网络服务。
二、开发语言的语法与语义不同
在开发语言上, ASP采用脚本语言VBScript、Java Script作为自己的开发语言。ASP.NET则使用
.NET Framework所支持的Visual Basic.NET、C#、JScript.NET等语言作为其开发语言, 这些语言生成的网页在后台被转换成类, 并编译成一个DLL。
(一) 与ASP.NET相比, ASP在API方面完全兼容, 但有三处不同:
1.Request () :ASP返回字符串数组;ASP.NET返回字符串;
2.Request.Query String () :ASP返回字符串数组;ASP.NET返回字符串;
3.Request.Form () :ASP返回字符串数组;ASP.NET返回字符串。
在ASP中, Request、Request.Query String和Request.Form集合从查找返回字符串数组。例如, 在ASP中, 按如下所示访问从请求到http://localhost/test/test.asp?values=45&values=600的查询字符串值:
在ASP.NET中, 这些集合需要显式方法来获取数组访问, 这些数组现在也是从0开始索引。按上述例子的要求, 在ASP.NET中的查询字符串值:<%
(二) ASP.NET页与ASP页相比还有几处语义变化
1. ASP.NET页仅支持单语言
ASP允许在单页上使用多种语言, 这对脚本库方案有用;由于ASP.NET的已编译特性, 它在一页上仅支持单语言。但在单个应用程序内仍然可有多个使用不同语言的页。用户控件还可以具有不同于包含它们的页所使用的语言, 从而拥有在单页内集成用不同语言编写的功能。
2. ASP.NET页函数必须在