摘要：分层是用来分割复杂软件系统的最常用手段之一。如：操作系统建立在设备驱动和CPU指令上；FTP建立在TCP层之上，TCP建立在IP层上，IP建立在以太网上。 把分层结构想像成蛋糕，每一层都建立在它下一层上。意味着上层使用下层的服务，但是对更底层的服务一无所知。如，第四层使用第三层定义的服务，第三层使用第二层的服务，但是第四层并不了解第二层的服务。 分层的优势： 可以单独了解一层的东西，而不用管其他层 可以替换某一层的实现 最小化层之间的依赖 为建立标准做好准备 一个低层可以被很多高层使用（提高复用率） 分层的劣势： 分层对部分东西，而不是全部东西，有一个良好的封装。有时会引起连锁的更改，如，为了在用户界面上多显示一个属性，必须更改从数据库到UI之间的所有层。 额外的层会降低性能 阅读全文

摘要：我的前两篇blog原意是想通过一个故事说明委托的来龙去脉，但是后来的主题却变成了解耦的一些方法介绍，对于委托本身的关注反而少了，加上编故事的水平不高，有点虎头蛇尾的感觉，大家见谅，以后有机会再来好好整理以下。 在网上找几篇好文来补充一下委托的内容： 台湾msdn的大内高手专栏，蔡学镛先生的好文（繁体+台湾术语，希望大家看得懂）： 函数指针进化论（上） 函数指针进化论（下） 阅读全文

摘要：什么？！更改接口？ 随着时间的流逝，市面上开始布满了使用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线程可以同时在这一个被返回的对象实例上安全的调用这个方法. 阅读全文