摘要： 什么？！更改接口？ 随着时间的流逝，市面上开始布满了使用tmfc的开关的产品，看着自己的产品受到大家如此热烈的欢迎，tmfc感到无比的满足。但是他还是发现有些产品没有使用他的开关，他感到纳闷，“为什么你们不在这个台灯上装开关呢？”他指着装有老式插口（可以把两根电线的其中一根更换插槽来实现不同功能的控制装置，在开关发明之前统治着这个紧耦合的世界）的台灯向厂家的促销员问道。“您有所不知啊！说起... 阅读全文

摘要： 开关的诞生 话说在一个紧耦合的世界，有一个名为tmfc的工匠，一天，他发明了一个叫做开关的的设备。他琢磨了老半天，决定把开关装在自己的床头，这样他就不用在睡前起床去拔电灯的电线了（这可是个紧耦合的世界啊），tmfc对自己的发明非常满意。 class Switch{ Light light; public void Switch(Light l){ light = l; } public void TurnOn(){ light.On(); } public void TurnOff(){ light.Off(); } } 阅读全文

摘要： [翻译]了解ASP.NET底层架构(一) [翻译]了解ASP.NET底层架构(二) [翻译]了解ASP.NET底层架构(三) [翻译]了解ASP.NET底层架构(四) [翻译]了解ASP.NET底层架构(五) [翻译]了解ASP.NET底层架构(六) [翻译]了解ASP.NET底层架构(七) [翻译]了解ASP.NET底层架构(八) [翻译]了解ASP.NET底层架构(完) 完整Word文档下载[... 阅读全文

摘要： 唷-我们已经走完了整个请求处理过程了.这过程中有很多底层的信息,我对HTTP模块和HTTP处理器是怎么工作的并没有描述的非常详细.挖掘这些信息相当的费时间,我希望在了解了ASP.NET底层机制后,你能获得和我一样的满足感. 在结束之前让我们快速的回顾一下我在本文中讨论的从IIS到处理器(handler)的过程中,事件发生的顺序 IIS获得请求 检查脚本映射中,此请求是否映射到aspnet_isapi.dll 启动工作进程 (IIS5中为aspnet_wp.exe,IIS6中为w3wp.exe) .NET运行时被载入 阅读全文

摘要： HttpHandlers 模块是相当底层的,而且对每个来到ASP.NET应用程序的请求都会被触发.Http处理器更加的专注并处理映射到这个处理器上的请求. Http处理器需要实现的东西非常简单,但是通过访问HttpContext对象它可以变得非常强大.Http处理器通过实现一个非常简单的IHttpHandler接口(或是它的异步版本,IHttpAsyncHandler),这个接口甚至只含有一个方法-ProcessRequest()-和一个属性IsReusable.关键部分是ProcessRequest(),这个函数获取一个HttpContext对象的实例作为参数.这个函数负责从头到尾处理Web请求. 单独的,简单的函数?太简单了,对吧?好的,简单的接口,但并不弱小!记住WebForm和WebService都是作为Http处理器实现的,所以在这个看上去简单的接口中包装了很强大的能力.关键是这样一个事实,当一个请求来到Http处理器时,所有的ASP.NET的内部对象都被准备和设置好来处理请求了.主要的是HttpContext对象,提供所 阅读全文

摘要： “流过”ASP.NET管道 HttpApplication触发事件来通知你的程序有事发生,以此来负责请求流转.这作为HttpApplication.Init()函数的一部分发生(用Reflector查看System.Web.HttpApplication.InitInternal()方法和HttpApplication.ResumeSteps()方法来了解更多详情),连续设置并启动一系列事件,包括执行所有的处理器(handler).这些事件处理器映射到global.asax中自动生成的哪些事件中,同时它们也映射到所有附加的HttpModule(它们本质上是HttpApplication对外发布的额外的事件接收器(sink)). HttpModule和HttpHandler两者都是根据Web.config中对应的配置被动态载入并附加到事件处理链中.HttpModule实际上是事件处理器,附加到特殊的HttpApplication事件上,然而HttpHandler是用来处理”应用级请求处理”的终点. HttpModule和HttpHan 阅读全文

摘要： HttpRuntime,HttpContext和HttpApplication 当一个请求到来时,它被路由到ISAPIRuntime.ProcessRequest()方法.这个方法调用HttpRuntime.ProcessRequest方法,它作一些重要的事情(用Reflector查看System.Web.HttpRuntime.ProcessRequestInternal方法): 为请求创建一个新的HttpContext实例 获取一个HttpApplication实例 调用HttpApplication.Init()方法来设置管道的事件 Init()方法触发开始ASP.NET管道处理的HttpApplication.ResumeProcessing()方法 阅读全文

摘要： 回到运行时 在这里我们有一个在ISAPI扩展中活动的,可调用的ISAPIRuntime对象的实例.每当运行时是启动的并运行时,ISAPI的代码调用ISAPIRuntime.ProcessRequest()方法,这个方法是真正的进入ASP.NET管道的入口.这个流程在图4中显示. 记住ISAPI是多线程的,所以请求也会通过AppDomainFactory.Create()(译注:原文为ApplicationDomainFactory,疑有误)函数中返回的引用在多线程环境中被处理.列表1显示了ISAPIRuntime.ProcessRequest()方法中反编译后的代码,这个方法接收一个ISAPI ecb对象和服务类型(WorkerRequestType)作为参数.这个方法是线程安全的,所以多个ISAPI线程可以同时在这一个被返回的对象实例上安全的调用这个方法. 阅读全文

摘要： 进入.NET运行时 进入.NET运行时的真正的入口发生在一些没有被文档记载的类和接口中(译著:当然,你可以用Reflector来查看J).除了微软,很少人知道这些接口,微软的家伙们也并不热衷于谈论这些细节,他们认为这些实现细节对于使用ASP.NET开发应用的开发人员并没有什么用处. 工作进程(IIS5中是ASPNET_WP.EXE,IIS6中是W3WP.EXE)寄宿.NET运行时和ISAPI DLL,它(工作进程)通过调用COM对象的一个小的非托管接口最终将调用发送到ISAPIRuntime类的一个实例上(译注:原文为an instance subclass of the ISAPIRuntime class,但是ISAPIRuntime类是一个sealed类,疑为作者笔误,或者这里的subclass并不是子类的意思).进入运行时的第一个入口就是这个没有被文档记载的类,这个类实现了IISAPIRuntime接口(对于调用者说明来说,这个接口是一个COM接口)这个基于Iunknown的底层COM接口是从ISAPI扩展到ASP.NET的一个预定的接口.图 阅读全文

摘要： IIS 5 和6以不同的方式工作 当一个请求来到时,IIS检查脚本映射(扩展名映射)然后把请求路由到aspnet_isapi.dll.这个DLL的操作和请求如何进入ASP.NET运行时在IIS5和6中是不同的.图2显示了这个流程的一个粗略概览. 在IIS5中,aspnet_isapi.dll直接寄宿在inetinfo.exe进程中,如果你设置了Web站点或虚拟目录的隔离度为中或高,则会寄宿在IIS单独的(被隔离的)工作进程中.当第一个ASP.NET请求来到,DLL(aspnet_isapi.dll)会开始另一个新进程aspnet_wp.exe并将请求路由到这个进程中来进行处理.这个进程一次加载并寄宿.NET运行时.每个转发到ISAPI DLL的请求都会通过命名管道调用被路由到这个进程来. 阅读全文