博客园_GodSpeed

如何开始对项目进行管理（三）

2011-08-15T17:48:00Z

（五） review和重构

说到review，有些筒子可能立刻就想到了：吵架。确实，有的时候review真的可能演变成吵架，但是我们为了项目的成功，这个风险一定要冒，慢慢成熟以后，被人批评的次数多了，脸皮厚点儿就好了。；）玩笑归玩笑，review确实是需要技巧的：在review别人的代码时，要注意你的话语有时会伤害别人的自尊心，让别人觉得你是在鸡蛋里头挑骨头；在别人review你的代码时，同样的你也会觉得别人是在鸡蛋里头挑骨头，伤害你的自尊心。这里我也没有太多的技巧可言，一句话，换位思考，脸皮厚点儿吧。哈。

Review可能分成以下几种：

1，设计的review。说起review大家更多想到的是大家坐在一起边侃大山边看别人的代码，其实设计的review是更加重要的和更加高级的，也是更有价值的，问题发现的早解决的代价就小嘛。在review别人或者自己的设计时，我们都能学到别人的设计理念，方法和技巧，这能大大提高团队成员的能力。项目中的技术牛人，项目经理和技术骨干应该作为设计review的主力人员，多多谈谈自己的看法；同时也要注意尊重设计者的感情，让大家都有收获的同时，把项目做好。

2，代码的review。代码review的形式可以多种多样，两个人坐在一起看看代码也是一种review，也没有必要非得所有人都凑齐。Review代码的可以让自己迅速成长，也能让项目组成员熟悉别人的业务和代码，以最大程度减少人员变动造成的损失；同时也能让代码规范更加一致。

不管是设计review还是代码review，都不一定要全部人员到场，这可能会浪费一些时间；但是设计的review最少要有一个技术骨干或者项目经理在场，否则review就会变成讨论会进而升级成战争。

Review有时候也会被认为浪费时间，特别是很多程序员对review别人的代码没有任何兴趣，也不愿意让别人对自己的代码说三道四。我想说，作为一个二十一世纪的软件工程师，我们不但要善于对技术进行钻研，更要善于把自己的技术传播出去，也要善于通过别人的指点更快的提高自己的工作能力。这是一个开放的时代，是一个需要交流的时代，是一个迅速发展的时代，你慢，就就完蛋。

在review发现了很多问题之后，我们要怎么办呢？对，重构。这几年重构这个词已经非常的火了，大家都说重构很重要，但是又有几个人真正的去重构呢？有几个人真正的不允许自己写重复代码呢？大家是不是还在说：“项目schedule太紧了，等有空了再优化吧”？我认为，这句话是有问题的，项目的总时间短，任务重，我们没办法；但是优化（重构）却不会增加这种时间的压力，相反的，重构会大大减少后续的开发和debug时间。因为重构后，出现的bug更容易被定为，更容易被fix；相反垃圾代码引起的debug和fix bug的时间将远远大于重构的时间。

本文链接

如何开始对项目进行管理（二）

2011-06-08T02:57:00Z

（三） 我们需要哪些文档，工具和努力

软件项目肯定离不了文档和管理工具，如果您的项目还没有它们，那么请从现在开始。那么文档是不是越多越好呢？老话说的好，合适的才是最好的。小而精的文档和工具会让我们事半功倍，大而全的文档会让我们疲于奔命，最后迷失在文档的海洋中。

我们写代码的都知道，错误的注释比没有注释更可怕；同样的，没有及时得到更新的文档比没有文档更可怕，因为文档就是项目的注释。那么我们是否有必要去更新那些我们根本没有用到的文档呢？很显然，那是非常没有必要的，是对资源的浪费。文档说起来其实就是一个工具，是一个让我们开发时有依据，可以追溯开发过程以及记录开发结果的工具。我们只有用到它，它才有存在的必要。

那么文档过于少或者干脆没有文档，不是更简洁？我想说：不写代码不是更简洁？玩笑归玩笑，没有文档或者文档太少会导致的问题大家可能也都遇到过：那就是过程不可追溯，有些非常重要的逻辑没有记录，需要用到时团队成员各执一词，甚至需要重新找客户确认而是客户认为我们不够专业；有些非常重要的设计没有记录，导致代码维护困难，以至于维护人员破口大骂开发人员写的什么垃圾代码做的什么垃圾设计。有些设计非常的巧妙，非常的值得学习，然而就是因为没有留下记录而被初学者如我一样的人骂了N次。在反省自己不够聪明时，是否也该让写代码的人反省一下为什么没能留下点儿记录？

有一种观点是最好的设计就是代码，意思是代码就是设计，代码应该非常的优秀，可读性特别好，让人一看就明白，我完全同意。如果代码写到这种程度，那文档就真的没用了。那么请自问，您是这样吗？如果是，没文档，没问题；如果不是，请把重要的东西写下来。那么，哪些是重要的呢？

哪些是必须的，哪些是Optional的。对于哪些文档更重要些，应该由项目的具体情况而定，特别是项目的大小，逻辑的复杂程度，人员的情况等等很多因素。在我做过的项目中，我个人认为最重要的一些文档和工具如下所述：

1，功能说明书（Functional Specification）------按独立功能划分优先级，每一条记录都是一个可交付物，都是一个功能。整个文档就描述了整个项目的交付功能和优先级。项目中的所有人，都应该关注这个文档：测试用它来写测试用例；开发人员用它来决定先开发哪个功能；PM用它来查看功能的完成和验证状态。它通常不应该内容过多（由项目规模决定），我觉得最多两行字就可以描述一个独立工作的功能，至于对这个功能的理解，应该由负责它的程序员来完成。

2，核心流程图。这个流程图可能描述了用户使用该系统的过程；也可能描述系统中数据的流转；也可能描述表单的流转。总之，它描述一个过程，这个过程对用户来说非常重要。这个图有时候也会被其它的图，如顺序图代替。

3，部署文档。该文档描述了该系统应该如何部署，它不一定非要是一个word文档，也可能仅是一个bat文件而已。这个文档应该描述该项目如何部署，步骤是怎么样的，需要哪些文件，需要哪些硬件支持，以及需要注意什么。部署历来都不太被重视，大家觉得只要东西做出来了，部署不就是放上去吗？其实不然。在经历了一定周期的开发后，开发过程中积累的配置，对环境的要求，在真正部署的时候很多就忘了，所以部署可能会花费很多没必要的时间，我觉得这也是微软要做daily build的原因之一，每天都build一个可用的版本，当然部署就没有问题了。我们刚开始可能不需要每天都build一个版本，但最少要一周或者两周部署一个版本吧。每次部署都整理一个自动化的脚本或者文档，会让你最后上线的时候非常的从容。

4，测试用例。我不是一个测试人员，测试也是我觉得一直没有做到位的地方。客观的说，我觉得用例应该花很大心思去编写，就像用户真正的在使用软件一样。项目应该在设计和开发的时候就以满足用例为目标，而不是开发完了才想起来用例，去测试，发现问题再修改，回头想想，这可能就是测试驱动开发产生的原因吧。我们知道用户发现错误修改的成本高于我们自己发现的错误；同样的，设计和开发阶段就解决的问题成本也远远小于测试阶段发现的。正是，问题发现的越早，解决起来就越容易，成本就越低。

5， Bug管理工具。这个管理工具可以是一个excel，当然，我并不推荐这么做，毕竟excel却是不那么自动化。但是，只要比excel自动化一点点儿的信息系统就可以了，它需要可以记录问题，可以传截图，这就够了。我推荐使用bug tracker，这是个dotnet开发的开源的bug管理工具，其实也可以管理需求，是非常实用的。

以上五个是我认为最重要的，我觉得是项目开始进行管理的阶段必不可少的；而下面几个，则是大家视情况可选的。

6，核心类图。这个可能是可选的，因为有时候，类的关于没那么复杂，也就没有必要有这个图；相反，则需要进行记录。

7，数据库设计。数据库设计文档可能在review的时候用到。

8，系统间接口图。如果产品有若干个子系统，如web service等等，那么我认为需要一个描述系统间接口和交互关系的图，这个图应该在设计的早期就开发出来供大家使用并且随时保持更新和关注。

有了文档和工具，是不是就一切OK了呢？不对，就像大而全的文档并不能帮助我们成功一样，有了文档并不代表项目就能成功，如何维护和使用这些文档和工具是相当重要的。每个文档都应该有人去维护，那么谁去做这个事呢？我认为项目经理应该经常拿着功能说明书开会，它也可以被看做是WBS的初级版本，可以被标注状态和优先级；所有人都应该熟悉流程图，并随时提出对流程图进行检验和review；应该指定一个人负责构建，这并不需要花费很多时间，但是需要细心和一些完美主义精神；测试人员自然要维护好测试用例；每个人特别是开发人员，都应该有一种觉悟，那就是一旦想起了哪些重要的逻辑，不管是业务的逻辑还是系统的算法，都应该记录到bug管理工具上。Bug管理工具完全可以记录这些零散但却重要的东西，以便将来方便查询。

在这里我也是根据自己的经历简单的谈了一些我的看法，这并不是金科玉律，我还得说，合适你的才是最好的。

（四） 代码规范的选择

做开发不可避免的遇到代码规范，从上学时就会学习到一些规范，但是每个公司都不同，那么我们到底要遵守哪些规范呢？我个人认为，一个合格的程序员应该可以随时调整自己适应任何一种规范，这是一种职业素养和能力。而何时该遵循何种规范，这也有一定的原则。

1，在现有系统（代码）基础上进行开发。这种情况下，我们应该尽量的去遵循原有系统的规范，不论是命名还是注释。因为如果这时你非要按照自己的习惯写，那么系统就会出现两种完全不同风格的代码，这对将来的维护是一种噩梦。但是，遵循原有规范不是迁就原有错误。如果发现原有的规范会造成一定的问题，就要立刻改正，不能装傻充愣假装看不见。

2，新建团队开发新的系统。新建的团队中团队成员可能来自不同的环境，对规范的选择倾向一定是不完全一样的，此时要怎么做呢？这时，项目的领导者应该组织大家一起做一个决定，讨论如何定义变量，如何给控件取名等等。在出现意见不统一又谁都说服不了谁的情况时，项目经理应该做出明确的决定。此时选择一种规范远比同时迁就两个人要来的好，不然造成新系统中存在两种规范，同样是维护的噩梦。

3，稳定团队开发新的系统。这种情况就容易得多，团队稳定后团队成员渐渐的了解了互相的习惯，互相学习后就更容易达成妥协。只要注意让新加入的成员适应就可以了。

有人可能觉得代码规范没什么大不了，功能正确没有bug不就行了？当然，如果没有bug那肯定没问题，然而一个系统运行到退休还没有bug，哪位见过呢？我做了一些运维工作之后才渐渐了解到，不同风格的代码读起来就像是一会儿在赤道，一会儿在南极，非常的痛苦，有时甚至会造成系统很多的不一致，大大增加了维护的工作量。我们的目标之一不就是增加系统的可维护性吗？

本文链接

如何开始对项目进行管理（一）

2011-06-07T14:20:00Z

引言谁应该对项目进行管理

项目管理的的文章和书籍到处都是，我也不敢在这班门弄斧。所以以下的文字主要关注从没有管理到开始对项目进行一些管理这个过程，通常没有进行管理或者很少进行管理的项目也不会特别大，所以本文并不一定适合大型项目。本文也不完全符合某一流程或者标准，其中一些只是我个人的一些浅见，如果能抛砖引玉，那就再好不过了；如果哪里说的不对，肯定各位筒子们尽管拍砖。

作为项目组的成员之一，不论你是开发工程师，测试工程师还是数据库工程师，你都对项目管理负有责任。在工作中，工程师应该精通自己的部分，优秀的工程师还应该熟悉别人的部分，实际情况中的工程师通常还需要在必要的时候（有人离开）顶上去做任何一个部分，此时，对项目的整体的把握至关重要。在参与到管理的过程中，也会提高自己的项目管理能力。其实，“项目管理”四个字重点不在管理，而在项目，当你的心在项目上，你就是管理者，项目就有可能因为你而成功；反之，即使你是个小角色，项目也可能因你而面临失败的危险。

（一） 我们需要什么样的人

在前面的文字中，我提到项目中的人员。我个人通常喜欢称项目的参与者为“工程师”，不管是开发，测试还是数据库管理，还是需求分析，项目管理人员。工程师这个词，其实包含了很多内容，不仅仅是垒代码，而是要像做一个建筑工程一样，考虑自己的部分对其他部分的影响，设计自己的部分，构建自己的部分，测试自己的部分，这是一个有机互动的过程，不是一个简单机械运动。我要强调的是工程师是技术工种，不是熟练工种，作为项目组的一员，我们也要从内心去做一个技术工种而不是熟练工种。

基于以上的考虑，我认为项目组成员应该至少具备如下三个特征：

1，具有本领域内基本的技术能力和学习能力。我坚信不知道开机按钮在哪的同志确实干不了修理电脑的活儿，也不认为三天学不会hello world的程序员还有在这个领域生存的机会。

2，专注于工作的精神。哪怕你工作一分钟，也请专注的工作，专注的思考。专注成就价值，只有专注的做事情，才能有所斩获。

3，能够与人沟通。众所周知，沟通对于项目的成功有多么重要，所以沟通是项目组成员比不可少的素质之一。

工程师，还是代码工人。你的选择？

（二） 始终关注交付物--不管是项目经理还是开发人员（项目中的所有人）

项目一开始，我们就开始和客户谈需求。“汽车怎么卖跟我程序员有什么关系？如何让你的客户满意又关我什么事？只要告诉我你要什么就行了嘛，废话这么多”，很多程序员都这么想。

随着这些我们并不关心的事情越谈越多越谈越深入，我们越不耐烦，越想早点儿结束，进入我们自己的代码的世界。此时，我们忘记了真正重要的真正最核心的东西：我们要交付什么东西！此时你会说，我没有忘记，我就是要做个B2B的电子交易平台。没错儿，就是它，但是它是什么呢？包括什么呢？为什么是这样的呢？将来有可能会变成什么样呢？甚至这个平台能为我们的客户带来什么呢？不知道你能回答上来多少。

我们的交付物---它可能是一个独立工作的功能，可能是一个部署的方案，也可能是一个帮助文档，它才是值得我们一直关注并且必须要关注的东西。对于它，我们应该深入的去了解，它能干什么？为什么要这么干或者能为客户带来什么？在整个项目中处于什么位置？关键的挑战在哪里？何时交付最给力？最晚何时交付还能有效？如果没能交付会有什么后果，还有替代方案吗？

为了了解我们的交付物，我们必须深入的了解客户的需求。当我说到需求，我不想你联想到海量的客户业务信息，虽然那也是我们需要了解的；我只想让你去深入了解当前你在思考的交付物，以及跟它有关联的业务接口，当然，还有它产生的影响。关注交付物的最大好处就是能够保证项目的交付，而最核心的技术就是学习客户的业务—虽然我们是程序员，但其实我们应该是全才。

在此过程中，原型法是个不错的主意。原型不一定是一个客户看的东西，我不太看重那些重型的花费太多精力的原型。有时候，一个流程图，简单的几行字，几条描述业务的问题，一段与用户关于功能点的深入短暂的交谈，都是很好的原型。原型其实就是将你理解的东西，让用户理解，并得到用户的反馈，不管用什么方式，只要达到这个目的，那你的原型就成功了。

最后，一切关注交付物的努力都将迎来收获的季节：验收。项目组员可能关注交付物，而项目领导者可能更关注验收。其实关注交付物，就是关注验收，因为验收就是由一系列的交付物组成。乍一看，验收貌似就是一堆代码或者一堆文档，其实不然。验收其实是一个过程，是一个从开始就需要得到关注的过程。在项目开始的计划和设计阶段，每一个交付物都应该有一个完成的标准，即做到什么时候为止，一切交付物都应该是可验证的，而这种验证方式应该得到客户的认可。这些验证方式可以是一些测试用例，也可以是一些其它的标准，但是必须得有，我们一切的工作都要围绕这个验证标准进行。要努力让客户相信：验收就是跑完客户已经签字的测试用例，系统出现的错误在可以接受的范围之内。我们并不是欺骗客户，而是要客户进行深度参与，让它们意识到这些测试用例的重要性，从而更好的实现双赢。

本文链接

负载均衡随记

2011-05-08T05:56:00Z

1，单网卡单播 ---两台服务器不能互访

2，单网卡多播 ---外网不能访问web服务器了(可能由于路由器不支持多播）

3，双网卡多播 ---没问题， host parameter需要填负责通讯的网卡地址

本文链接

ASP.NET应用程序生命周期趣谈(五) IIS7瞎说

2010-09-27T03:52:00Z

Ps：建议初学者在阅读本文之前，先简要了解一下之前的几篇文章，以便于熟悉本文提到的一些关于IIS6的内容，方便理解。仅供参考。

PS：为什么叫瞎说呢？我觉得自己理解的并不到位，只能是作为一个传声筒，希望能给大家一些启发，引发一些讨论，来让大家更好的理解asp.net处理原理。有错误的地方，大家一定要指正，一定不要给我面子。谢谢大家。

在之前的几篇文章中，我跟大家分享了ASP.NET应用程序生命周期的一些知识，大多是在IIS6中。
随着技术的迅猛发展，IIS7逐渐的走入我们的视线，我相信未来也将全面代替IIS6等旧的版本。今天我们就来了解一下IIS7是如何工作的，它究竟能给我们带来什么。

我们知道，IIS6使用HTTP.SYS这个协议监听器来处理HTTP和HTTPS请求，IIS7也一样。HTTP.SYS是内核模式运行的，它替换了WINDOWS Sockets API（用户模式的）来接收请求。大家一听这“内核”肯定是要比“用户”厉害的嘛，好处我就不详说了。

下面我就说说说整个处理过程，从IIS6开始。

在IIS6中，www service管理IIS中Http的配置和管理，对worker process进行管理，对网站性能进行监控，工作能力可谓强大。然而在IIS7中，微软为www service进行了减负，www service不再兼任worker process的管理员，而仅仅是作为HTTP.SYS的适配器，主要职责就是配置HTTP.SYS。Windows Process Activation Service分享了www service之前的一些职能，包括管理应用程序池的配置和worker process的管理。最大的改进在于：IIS7中asp.net管道和IIS管道被合并在了一起来处理请求（集成模式）。
这样做有什么好处呢？
在之前的IIS版本中，只有托管代码才可以使用IIS的module，先在所有的文件类型都可以使用这些module，也就是说，你可以为静态页面使用asp.net forms authentication和URL authorization；
消除了IIS和ASP.NET的重复特性。例如客户端在请求一个托管文件时，旧版本的IIS会先通过IIS管道再通过ASP.NET管道。先在，只需要通过集成管道调用IIS的验证模块就可以了；
在同一位置管理所有模块，而不是在IIS中和ASP.NET中个管理一部分，这就简化了配置和管理。

关于应用程序池，IIS7允许用户选择两种模式：经典模式和集成模式。集成模式就是我们刚刚提到的通过整个ASP.NET和IIS7变成集成管道来处理；经典模式就是IIS6中的模式分开管理。值得注意的是，IIS7在应用程序级别设置这种模式，所以我们才可以在同一server上运行两种处理模型的应用程序；而iis6在server级别设置worker process的隔离模式，所以我们只能使用一个处理模型（当然，也只有一种处理模型，那就是IIS+ASP.NET）

集成应用程序池模式
当一个应用程序池在集成模式下时，你可以利用IIS和ASP.NET的集成请求处理架构。当一个worker process在一个应用程序池中接收到一个请求时，这个请求通过一些列的事件列表进行传递。每个事件调用需要的默认和托管的模块来处理请求的对应的部分生成response。
集成模式有如下好处：
首先，IIS和asp.net请求处理模型被集成为一个统一的处理模型。这个模型消除了以前IIS和ASP.NET中重复的步骤，比如authentication。另外，集成模式使得托管特性的可用性扩展到所有的内容类型。

经典应用程序池模式
经典模式时，IIS7处理请求的方式和IIS6一模一样。ASP.NET请求首先通过IIS的默认处理步骤，然后被引入ASPNET_ISAPI在托管runtime中来处理托管代码。最后，请求再被路由回IIS，发送response。
这种IIS和ASP.NET分离的处理模型结果导致某些处理步骤重复，例如验证和授权。另外，托管代码特性，比如forms验证，也只能被asp.net应用程序使用（或者你写脚本映射所有的请求需要被ASPNET_ISAPI.DLL来处理）。
在升级产品环境到IIS7并指定应用程序模式为集成模式前，要确保在继承模式下对现有的应用程序进行兼容性测试。如果集成模式失败，就加到经典模式上来。

说了那么多与以往版本的不同，我们以HTTP请求为例来捋顺一下IIS7的处理过程：

首先，客户端通过Internet发过来HTTP请求，HTTP.SYS接收到该请求。HTTP.SYS随后通知WAS说：去获取配置信息。WAS的配置信息来自于ApplicationHost.config。然后WWW SERVICE会得到配置信息，比如应用程序池和站点配置。我们知道，IIS7中WWW SERVICE主要功能就是配置HTTP.SYS，它配置了HTTP.SYS后，WWW SERVICE将请求通知给WAS。
WAS收到请求（可以是HTTP或非HTTP）后就会进行如下处理过程：
检查worker process是否在运行。如果一个应用程序池已经有了一个worker process，则将请求传递给WP；否则将创建一个WP。
Worker Process处理了请求后就返回一个response给HTTP.SYS。最后客户端接收response。
Worker Process里面则对该请求进行了一系列处理，可能包括验证，授权，缓存，异常等等module。
整个处理过程可以用两张图来表示，如下：

IIS处理过程：

Worker Process处理过程：

本文已经不再是趣谈了，虽然无“趣”，却也算有理，欢迎拍砖。

相关链接：

ASP.NET应用程序生命周期趣谈(四) HttpHandler和页面生命周期

2010-07-15T05:03:00Z

PS:本文很长，建议倒杯水拿点儿干粮再回来看，谢谢。

在之前的三篇文章中，我们还算简明扼要的学习了asp.net的整个生命周期，我们知道了一个Request进来以后先去ISAPI Filter，发现是asp.net程序后又ASPNET_ISAPI.dll这个ISAPI Extension来进行处理。在ASPNT_ISAPI创建了Worder Process后，在管道中经过HttpModule的处理来到HttpHander的手中。

我们知道P_Handler程序员使用“乾坤大挪移”对页面进行了处理后又通过管道中的HttpModule把response返回给了客户端。

那么，这么

l 所谓的“乾坤大挪移”到底是个什么功夫呢？

l P_Handler又是如何被调用如何消亡的呢？

l 我们自己是否也可以创建HttpHandler呢?

l HttpHandler和我们常用的.ashx又是什么关系呢？

我们就通过今天的简单讲述让大家对这些过程有个大致的了解。

从字面上我们也可以看出，HttpHandler就是handle http（request）的，就像程序员，就是（做）程序的人员一样，所以P_Handler就是个典型的HttpRequest处理人员。我们也知道IHttpHandler接口，它就像是一个认证，任何通过了IHttpHandler认证（实现了这个接口）的人员（handler），都可以处理HttpRequest。这个认证主要有两个内容（方法）：1，ProcessRequest；2，IsReusable。

ASP.NET默认有很多个Handler，它们处理了各式各样的asp.net文件，例如.config，.cs，.aspx等等。通过路径C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config找到web.config文件我们可以发现系统预定义的httphandler，因为太多在这就不一一列举。

通过<add path="*.config" verb="*" type="System.Web.HttpForbiddenHandler" validate="true" />我们可以知道我们项目中的web.config文件为什么不能访问了，原来是被 HttpForbiddenHandler给屏蔽了，我估计它是直接返回了一个错误，这样我们就不能访问这些资源，同样的，.sitemap, .asax, ..cs, .csproj等等我们熟悉的项目中的文件都是使用HttpForbiddenHandler来屏蔽掉的。

而但是通过<add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="true" />我们也可以发现原来.aspx是通过PageHandlerFactory来处理的。那么PageHandlerFactory又是什么东西呢？

通过反编译PageHandlerFactory我们可以看到：

1 public class PageHandlerFactory : IHttpHandlerFactory2, IHttpHandlerFactory
2 {
3     // Fields
4     private bool _isInheritedInstance;
5     // Methods
6     protected internal PageHandlerFactory();
7     public virtual IHttpHandler GetHandler(HttpContext context, string requestType, string virtualPath, string path);
8     private IHttpHandler GetHandlerHelper(HttpContext context, string requestType, VirtualPath virtualPath, string physicalPath);
9     public virtual void ReleaseHandler(IHttpHandler handler);
10     IHttpHandler IHttpHandlerFactory2.GetHandler(HttpContext context, string requestType, VirtualPath virtualPath, string physicalPath);
11 }
12

这个page handler的工厂通过GetHandler得到了一个IHttpHandler，这个Handler是什么呢？答案就在GetHandlerHelper方法中：

1 private IHttpHandler GetHandlerHelper(HttpContext context, string requestType, VirtualPath virtualPath, string physicalPath)
2     {
3         Page page = BuildManager.CreateInstanceFromVirtualPath(virtualPath, typeof(Page), context, true, true) as Page;
4         if (page == null)
5         {
6             return null;
7         }
8         page.TemplateControlVirtualPath = virtualPath;
9         return page;
10     }
11

我们可以清楚的看到，这个方法返回了一个Page，wow，原来Page类就是处理.aspx文件的HttpHandler啊，看到Page类的定义：

public class Page : TemplateControl, IHttpHandler{

}

我们更是确信无疑：System.Web.UI.Page就是处理.aspx页面的那个程序员P_Handler。这种程序员很平凡，却是不可或缺的，因为他们承担着一线的大量工作任务。而PageHandlerFactory就是专门培训这种处理页面的程序员的培训机构。这种培训机构很多，也就培养了各种各样的Handler，而我们自己也可以创建自己的培训机构，培训自己的HttpHandler，只要通过IHttpHandlerFactory这个认证（接口实现）就可以了。Page类是我们最常用的P_Handler程序员，它就像.net初级程序员一样普遍，只不过它不像我们这样什么都会，它只处理页面（因为它在一个大公司，微软啊，分工多明确啊）。

微软有程序员，我们也可以有，那么接下来我们就自己创建一个HttpHandler，我们用它来Handler我们定义的后缀名.godspeed文件。这个过程分为三步：

首先，我们创建一个实现了IHttpHandler的类

然后，在web.config文件中添加一行文字以便让server知道该如何处理.godspeed后缀名文件

最后，我们在IIS中映射我们的新后缀名到asp.net，好让IIS可以把这个文件传给ASP.NET进行处理并返回我们期望的结果。好，开始做。

1，创建名为TestCustomHttpHandler的网站

2，添加test.godspeed文件到网站中

3，创建GodSpeedHttpHandler.cs文件，代码如下：

1 public class GodSpeedHttpHandler:IHttpHandler
2
3 {
4
5 public GodSpeedHttpHandler()
6
7 {
8
9 }
10
11 #region IHttpHandler Members
12
13 public bool IsReusable
14
15 {
16
17 get { return true; }
18
19 }
20
21 public void ProcessRequest(HttpContext context)
22
23 {
24
25 HttpResponse response = context.Response;
26
27 response.Write("<html><body><h1>This is GodSpeed Handler! See, easy!</body></html>");
28
29 }
30
31 #endregion
32
33 }
34
35

4，配置web.config

</handlers>

5，映射到IIS和asp.net

6，访问test.godspeed

多简单啊各位看官可是看明白了？不明白没关系，欢迎回复和拍砖。

而我们常用的ashx也一种非常简单的handler，它通常用来处理不需要回传的任务，比如生成动态图片等等，园子里有很多这样的示例，在这里就不详述了。

那么我们之前提到Page类只处理页面，它也是我们最最常用的，最最重要的P_Handler程序员，它究竟是如何工作呢？它的工作对我们的日常开发又有什么影响呢？在下一篇文章中我将着重讲解页面生命周期—也就是Page类的ProcessRequest都引发了哪些事件以及在这些事件中我们能做些什么进行深入的探讨。

话说我们今天的重中之重：页面生命周期，说的就是Page类在处理页面的过程中都发生了哪些事件，而这些事件又是按照什么顺序发生的。ASP.NET的页面生命周期跟我们之前的理论讲解完全不同，它具有非常强大的实用性，所以我想通过一个小例子来进行解释和说明，以便让大家看起来更清晰和容易理解。因为Page类的ProcessRequest方法实现非常的复杂，我把代码反编译过来给大家看我觉得也没什么意义，所以我就着重给大家看一下整个页面的事件是以何种顺序被引发的，以及在这些事件中，我们能做什么。在这个过程中，我们主要关注如下问题：

1，事件的执行顺序

2，控件何时被初始化（我们什么时候能用它）

3， ViewState何时可用

4，更改MasterPage和Theme

5，在各个事件中还能干什么工作

按照如下步骤建立示例：

一，我们创建一个website

二，加入两个MasterPage分别为site.master和map.master，分别在上面加一个label进行说明：this is site/map master page.

三，分别加入两个theme为BlueSkin和RedSkin,分别对button的背景色进行设置，一个是Blue，另外一个是Red

四，在default页面中加入两个label和一个button

五，Default页面代码如下：

1 private int step = 1;
 2 private string GetEventName(string eventName)
 3 {
 4 step += 1;
 5 return eventName;
 6 }
 7
 8 protected override void OnPreInit(EventArgs e)
 9 {
10 base.OnPreInit(e);
11 Response.Write(GetEventName("pre init event, this is the " + step + "th step!"));
12 //lblMessage.Text = "on pre init";
13
14 this.MasterPageFile = "map.master";
15 this.Theme = "BlueSkin";
16 if (lblMessage2 == null)
17 {
18 Response.Write("Server control has not been initialed on pre init");
19 }
20 else
21 {
22 Response.Write("Server control has been initialed here");
23 }
24 if(this.ViewState.Count>0)
25 {
26 Response.Write("ViewState can be used here, the ID is "+ViewState["ID"].ToString());
27 }
28
29 Response.Write(" ");
30 }
31 protected override void OnInit(EventArgs e)
32 {
33 if (lblMessage2 == null)
34 {
35 Response.Write("Server control has not been initialed on pre init");
36 }
37 else
38 {
39 Response.Write("Server control has been initialed here");
40 }
41 base.OnInit(e);
42
43 Response.Write(GetEventName("init event, this is the " + step + "the step! "));
44 if (lblMessage2 == null)
45 {
46 Response.Write("Server control has not been initialed on pre init");
47 }
48 else
49 {
50 Response.Write("Server control has been initialed here");
51 }
52 if (this.ViewState.Count > 0)
53 {
54 Response.Write("ViewState can be used here, the ID is " + ViewState["ID"].ToString() + "");
55 }
56 Response.Write(" ");
57
58 //this.MasterPageFile = "map.master";
59 //this.Theme = "BlueSkin";
60 }
61 protected override void OnInitComplete(EventArgs e)
62 {
63 base.OnInitComplete(e);
64 Response.Write(GetEventName("init complete event, this is the " + step + "th step!"));
65 if (this.ViewState.Count > 0)
66 {
67 Response.Write("ViewState can be used here, the ID is " + ViewState["ID"].ToString() + "");
68 }
69 else
70 {
71 Response.Write("ViewState can not be used here");
72 }
73 Response.Write(" ");
74 }
75 protected override void OnPreLoad(EventArgs e)
76 {
77 if (this.ViewState.Count > 0)
78 {
79 Response.Write("ViewState can be used here, the ID is " + ViewState["ID"].ToString() + "");
80 }
81 else
82 {
83 Response.Write("ViewState can not be used here");
84 }
85 base.OnPreLoad(e);
86 Response.Write(GetEventName("pre load event, this is the " + step + "th step!"));
87 if (this.ViewState.Count > 0)
88 {
89 Response.Write("ViewState can be used here, the ID is " + ViewState["ID"].ToString() + "");
90 }
91 else
92 {
93 Response.Write("ViewState can not be used here");
94 }
95 Response.Write(" ");
96 }
97 protected void Page_Load(object sender, EventArgs e)
98 {
99 Response.Write(GetEventName("page load system provided, this is " + step + "th step!"));
100 if (this.ViewState.Count > 0)
101 {
102 Response.Write("ViewState can be used here, the ID is " + ViewState["ID"].ToString() + "");
103 }
104 Response.Write(" ");
105 }
106
107 protected override void OnLoadComplete(EventArgs e)
108 {
109 base.OnLoadComplete(e);
110 Response.Write(GetEventName("on load complete event, this is the " + step + "th step! "));
111 }
112
113 protected override void OnPreRender(EventArgs e)
114 {
115 base.OnPreRender(e);
116 Response.Write(GetEventName("pre render event, this is the " + step + "th step! "));
117 }
118
119 protected override void OnPreRenderComplete(EventArgs e)
120 {
121 base.OnPreRenderComplete(e);
122 Response.Write(GetEventName("pre render complete event, this is the " + step + "th step! "));
123 }
124
125 protected override void OnSaveStateComplete(EventArgs e)
126 {
127
128 base.OnSaveStateComplete(e);
129 Response.Write(GetEventName("sae state complete event, this is the " + step + "th step! "));
130 }
131
132 protected override void Render(HtmlTextWriter writer)
133 {
134 base.Render(writer);
135 Response.Write(GetEventName("render function, this is the " + step + "th step! "));
136 }
137
138 protected override void OnUnload(EventArgs e)
139 {
140 if (this == null)
141 {
142 string aaa = string.Empty;
143 }
144 if (lblMessage2 == null)
145 {
146 string ga = string.Empty;
147 }
148 base.OnUnload(e);
149 if (this == null)
150 {
151
152 }
153 }
154
155 protected override void OnLoad(EventArgs e)
156 {
157 base.OnLoad(e);
158 Response.Write(GetEventName("page load we created, this is the " + step + "th step! "));
159 }
160 protected void btnSubmit_Click1(object sender, EventArgs e)
161 {
162 ViewState["ID"] = "12345";
163 Response.Write(GetEventName("button control click event, this is the " + step + "th step! "));
164 }

六，执行结果：

七，代码分析

a) 从执行结果我们可以看到，事件的执行顺序为：

i. PreInit

ii. Init

iii. InitComplete

iv. PreLoad

v. Load

vi. Control Event(if they have)

vii. LoadComplete

viii. PreRender

ix. PreRenderComplete

x. SaveStateComplete

xi. Render

xii. Unload

b) 从结果中我们也可以看到，在PreInit事件发生后控件还没有被初始化，也就是我们还不能使用。而在Init刚刚发生的时候已经可以使用了。也就是说，控件初始化发生在PreInit之后Init之前。总而言之，我们关心的是我们最早可以在Init事件里对页面server端控件进行操控。

c) 关于ViewState，本示例也清晰的显示出它在Init Complete之后还是不能使用，而在PreLoad刚刚发生的时候，就已经可以使用了。

d) 通过对比Default.aspx页面的配置我们知道，在PreInit里面的Theme和MasterPage的设置是生效了的，我们可以在PreInit里设置Theme和MasterPage，而在其它任何位置设置这两个东西都将抛出异常（看我注视掉的代码）

e) 其它的事件：

Load: 这个事件可能是大家最熟悉的了。需要注意的是，Page对象会递归的调用子控件的onload事件直到页面和所有的子控件被加载完成。这个事件主要用来设置控件属性的值，建立数据库连接（通常不这么做）。

Control events: 这个就不多说了，主要是处理控件的事件，例如click。这也就让我们明白了每次我们click一个Button的时候，实际上是要先去执行load事件然后才执行click事件的，一般我们用!IsPostBack来判断一下从而避免执行不必要的加载逻辑。

LoadComplete: 页面所有的控件都被加载以后执行，暂时没有想到用来干什么。。。

PreRender: 在HTML被生成之前这是最后一个事件。每一个页面中的控件都有PreRender的过程。在这里对将要输出的HTML结果进行最后一次修改。

SaveStateComplete: 在这个时间发生之前，已经保存了所有控件和页面的，任何对page或者控件的改动都不会产生左右。暂时没想到用来干啥。

Render: 它不是一个事件而是一个方法。工作就是把HTML写回客户端浏览器。

UnLoad: 页面中的每一个控件都会发生这件事。在控件中，使用这个事件来做清理工作，例如关闭数据库连接等。对与页面本身也是做清理工作，例如关闭打开的文件和数据库连接，或者结束日志或者其它指定的工作。

f) 关于Unload事件，它实际上做的是销毁前的工作。在Unload事件发生以后，Page类被卸载和销毁，所以page类的字段值也就消失了，而我们通常也是使用在SaveStateComplete之前保存的ViewState来存储哪些我们想要存储的page里的数据。HttpRuntime做了销毁Page的动作，同样也是它创建的Page这个handler，现在我们知道原来不是HttpApplication雇佣了P_Handler, HttpApplication只是使用了它而已，真正雇佣（创建）并解雇（销毁）P_Handler的是老板HttpRuntime。

整个ASP.NET生命周期基本结束，如果大家想更深入的了解其中内情，请反编译System.Web.HttpRuntime类。如果您不喜欢研究那么深入，我想我这几篇文章应该可以对您有些帮助。

我并不打算就此停手，接下来我还将会围绕ASP.NET生命周期和大家进一步深入探知iis6中的最重要的改进—Application Pool的奥秘和重要的HttpModule—-SessionStateModule。在这些都结束以后，我将接着跟大家学习ASP.NET在IIS7中的变化及相应的知识，欢迎大牛指导和拍砖，谢谢。

相关示例代码：

自定义HttpHandler和PageLifeCycle示例代码.zip

相关链接：

ASP.NET应用程序生命周期趣谈(三) HttpModule

2010-07-12T02:30:00Z

在之前的文章中，我们提到过P_Module(HttpModule)这个能干的程序员哥们儿，它通过在项目经理HttpApplication那里得到的授权，插手整个应用程序级别的事件处理。所有的HttpModule都要实现IHttpModule接口，那么我们看IHttpModule的定义：

namespace System.Web

{

public interface IHttpModule

{

void Dispose();

void Init(HttpApplication context);

}

可以看到，HttpModule主要就做了两件事，一个就是大家都明白的释放资源Dispose()，另一个则是初始化。用什么初始化呢？当然是HttpApplication。刚才已经说过，P_Module程序员是经过了项目经理HttpApplication的授权了的，这里我们就可以看到，初始化方法参数就是HttpApplication对象，那么HttpModule又是怎么处理应用程序级别的事件的呢？且看：

我们可以看到，项目经理HttpApplication可是实实在在的放权啊，它非常的相信P_Module可以做好这些事情，所以在初始化方法Init(HttpApplication context)中，程序员P_Module可以注册很多事件，比如说常用的BeginRequest, EndRequest, AuthenticateRequest, AuthorizeRequest等等，还有一些其它的不常用的事件我们就不再赘述。总而言之，HttpModule强大到可以插手整个应用程序周期的所有事件---因为得到了充分授权嘛。下面是注册BeginRequest事件示例代码：
public void Init(HttpApplication context)

{

context.EndRequest+= new EventHandler(context_EndRequest);

}

private void context_EndRequest(object sender, EventArgs e)

{

//do something when the request end

}

那么这里，我们要澄清一个问题：在ASP.NET应用程序生命周期趣谈(一)中我们曾经在后面提到“P_Handler自信的笑了一声，把箱子交还给了项目经理（HttpApplication对象）”，这是不完全准确的。事实上P_Module已经是一个非常高级的程序员，他在有必要的情况下（注册了EndRequest事件）是要review初级程序员P_Handler的工作的，这个review的事件就是HttpApplication的EndRequest的事件。当然，有时候也不review就直接交给HttpApplication了，所以我们得出结论：ASP.NET请求处理是基于管道模型的，request从管道这头进去，经过了HttpModule的一些列处理，到那头儿的HttpHandler再处理，最后再经过管道原路返回。一次请求HttpHandler只能有一个，而HttpModule却可以有若干个。（ps: --！真是废话，MSND上写的比谁都清楚）

总的来说，P_Module高级程序员主要就是从项目经理HttpApplication那得到授权（传入HttpApplication参数）处理应用程序级别的一些重要事件，这些事件贯穿整个应用程序生命周期。我们经常会使用到ASP.NET自带的HttpModule，也有时会使用自定义的HttpModule。ASP.NET自带的HttpModul在以下目录中可以找到：C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG/web.config

而我们自己编写的自定义HttpModule则写在我们的应用程序的web.config文件中，也是<HttpModules></HttpModule>节点下，与系统自动配置的并无不同：

可以看到，<HttpModules>节点是在system.web下面的，HibernateUtil就是我曾经写过的一个HttpModule，非常典型，大家可以参考。对与系统自带的HttpModule有很多，这里我就随便挑了一个SessionStateModule来给大家做一个大致的分析，以便大家了解HttpModule如何工作。

简单说一下什么事SessionState。SessionState就是asp.net处理Session的一种机制，简单来说就是它通过管理Session的存储位置，来优化Session的性能和安全性，避免浏览器禁用cookie时session丢失。ASP.NET允许Session存储在三个位置：aspnet_wp.exe(它崩溃session就丢失)；aspnet_state.exe(单独的stateserver)；sqlserver（存到数据库中）。关于SessionState的内容，请参阅其它相关文章，以后有机会我自己也会写写。

书归正传，那么我们通过反编译SessionStateModule，我们得到两行有用的代码：

public void Init(HttpApplication app)

{

SessionStateSection sessionState = RuntimeConfig.GetAppConfig().SessionState;

//从config文件中读取SessionState配置

this.InitModuleFromConfig(app, sessionState);

//初始化SessionStateModule需要处理的事件

//Other Code

}

第一行从config文件中读取了SessionState的配置（节点<configuration><system.web><sessionState>下面的内容，配置了怎么存储Session等信息），第二行则初始化了SessionStateModule需要处理的事件，我们再看看InitModuleFromModule干了什么：

private void InitModuleFromConfig(HttpApplication app, SessionStateSection config)

{

if (config.Mode != SessionStateMode.Off)

{

app.AddOnAcquireRequestStateAsync(new BeginEventHandler(this.BeginAcquireState), new EndEventHandler(this.EndAcquireState));

app.ReleaseRequestState += new EventHandler(this.OnReleaseState);

app.EndRequest += new EventHandler(this.OnEndRequest);

}

我们可以看到，第一行代码中，HttpApplication添加了OnAcquireRequestState的若干事件的处理方法，第二行添加了当SessionState释放时的处理方法，第三行则添加了request接触时的处理方法。SessionStateModule内部如何处理我们这里不做详述，但是我们可以清晰的看到，SessionStateModule处理了应用程序级别的时间，包括SessionState的获得，释放和Request的结束。我们没有发现它处理开始Request的事件，但我们确信它是有能力去做的，只是此种情形下并不需要那么做。下面按照执行顺序列出HttpApplication的事件列表以供参考：

1. BeginRequest //开始

2. AuthenticateRequest //验证

3. AuthorizeRequest //授权

4. AcquireRequestState //获取request state

5. ReleaseRequestState //释放request state

6. UpdateRequestCache //更新cache

7. LogRequest. //这个事件只支持.net 3.0以上版本和IIS7的集成模式

8. EndRequest //结束

所有的HttpModule（包括自定义的和系统自带的）均有能力处理这些事件从而对应用程序产生影响，看来这个P_Module程序员果然很牛啊，项目经理信任它并授权也是有道理的。

然后P_Module作为一个高级程序员，它自身知识积累固然很强大，它的学习能力也是不可忽视的。它可以自己学习（创建）一些新的能力（自定义Module），经典的例子就是它网上盛传的它能在每个页面中都加入一些文字；这里我只简单的说明我用过的一个P_Module自建的在EndRequest事件中关闭NHibernateSession的例子：

首先，我们创建一个类HibernateUtil，继承接口IHttpModule，并实现接口方法：

public class HibernateUtil : IHttpModule

{

public void Dispose()

{

}

public void Init(HttpApplication context)

{

}

然后，注册EndRequest事件：

public void Init(HttpApplication context)

{

context.EndRequest+= new EventHandler(context_EndRequest);

}

private void context_EndRequest(object sender, EventArgs e)

{

CloseSession();

}

最后，配置Web.config：

此时，我们就完成了一个自定义的HttpModule。这个小例子并不难，主要是说明了HttpModule的创建流程和方法，而本篇文章也难度也不是很高，希望对大家能有所帮助，欢迎拍砖，少扔鸡蛋，挺贵的，谢谢! ^_^

相关链接：

ASP.NET应用程序生命周期趣谈(一)

ASP.NET应用程序生命周期趣谈(二)

本文链接

ASP.NET应用程序生命周期趣谈(二)

2010-07-07T04:46:00Z

在上回书开始的时候我们提到博客园的IIS看了一眼我的请求后就直接交给ASP.NET去处理了，并且要求ASP.NET处理完之后返回HTML以供展示。

那么我们不仅要问：

1， IIS肯定是没有眼睛的啦，那它是怎么“看”的呢？

2，在“看”到了.aspx的页面请求后又是如何把它交给ASP.NET的呢？如果不做任何处理那它的存在又有什么意义呢？

3， ASP.NET收到这个处理请求后又是如何做的呢？它是怎么创建Context对象又是如何“雇佣”项目经理HttpApplication对象的呢？

本文将就这些问题进行深入而简单的探讨。

当你点击了这篇文章的链接，在很短的一段时间内博客园的IIS就收到了你的请求。它要“看”了。正如我们知道的，它没有眼睛，所以它依靠ISAPI来“看”请求的后缀。我们这次请求的是.ASPX文件。ISAPI是全称Inernet Server Application Programe Interface, 它就是IIS的眼睛和路由器，先看后缀然后分发给各个应用，我们可以通过访问IIS的站点的属性—》主目录—》配置来查看它的路由映射。

我们发现，在.aspx extension对应的Executable Path里，真正处理asp.net应用程序的是aspnet_isapi.dll。可以清楚的看到，它还能处理ASAX,ASCX, ASHX, ASD,BROWER,CD等等等一堆啊，真是功能强大。

然而，在“看”的方法方式上，IIS5和IIS6有一些不同。

IIS5通过inetinfo.exe进程在TCP端口（默认是80）来“看”那些进来的Request。正如我们刚才看到的，如果这些Request是需要aspnet_isapi.dll来处理，则aspnet_isapi.dll创建（不太确定worker process是不是aspnet_isapi.dll创建的，但是它们通过命名管道来交互）并持续监视一个aspnet_wp.exe进程，它就是asp.net最重要的组件：worker process。几乎所有的工作都是在这个进程中完成，它在IIS6中被改名叫做w3wp.exe。

IIS6则通过内核模式中的HTTP.SYS来“看”那些进来的Request。HTTP.SYS把进来的Request发送到相应的Application Pool（应用程序池）。应用程序池再把Request传递给aspnet_isapi来进行创建worker process的工作。IIS6中的worker process已经是w3wp.exe了。

接下来在最重要的worker process中发生了什么呢？项目经理HttpApplication又是怎么被雇来的呢？请听我慢慢道来。

ASPNET_ISAPI在创建了worker process加载了CLR完成了托管环境的布局后，就什么都不管啦。Worker process开始管理一切，它把所有的工作都交给了HttpRuntime。最后，是HttpRuntime雇佣了项目经理HttpApplication。然后，HttpRuntime并不是什么工作都没有做，它已经通过配置文件创建了所有的HttpModule并填写在了HttpApplication的“工作列表”中，项目经理HttpApplicaiton事根据这个列表来工作的。HttpRuntime也创建了HttpContext这个箱子并交给了项目经理HttpApplication。乎！现在我们终于理解“asp.net创建了HttpContext”这句话了吧。现在总结一下HttpRuntime都干了什么：

1，打造了HttpContext这个箱子来存储Request和Response

2，建立了工作列表HttpModule

3，雇佣了项目经理HttpApplication并把箱子Context交给它，然后把工作列表作为效绩考核列表也交给他。

4，等着返回结果

PS:在这个过程中，其实还有更详细的过程，但是我觉得那无助与我们理解真正的重要的东西，反而会带来更高的难度，所以也就没往上写。有兴趣的筒子们可以去微软网站搜索相关资源。

接下来，“项目经理”HttpApplication所作的事相信大家已经在前一篇文章中有所了解啦，什么？没看？那就赶紧去看看吧。

欢迎拍砖,谢谢

相关链接：

ASP.NET应用程序生命周期趣谈(一)

本文链接

ASP.NET应用程序生命周期趣谈(一)

2010-06-19T15:43:00Z

这几天一直在看ASP.NET应用程序生命周期，真是太难了，我理解起来费了劲了，但偏偏它又是那么重要，所以我希望能给大家带来一篇容易理解又好用的文章来帮助学习ASP.NET应用程序生命周期。这篇就是了。

当你访问博客园想看我的这篇文章的时候，这个请求就被博客园的WEB SERVER（IIS）接收到了。博客园IIS看了一眼我的请求，“噢，是.aspx啊，给ASP.NET去处理吧，就把我这个请求给了ASP.NET，并且说：“这个你来处理，你处理完了之后把HTML给我，我好给邱爽一个回复”。

ASP.NET收到IIS传递过来的请求后也没时间抱怨啊就开始干活儿了。怎么干的呢？

第一，它先创建了一个Context对象，它就像个箱子，箱子当然是来装东西的啦，装什么呢？

第二，ASP.NET创建了一个Request对象，包含了IIS传递给它的所有信息（IIS传递过来的实际就是个Request嘛）。

第三，ASP.NET接着又创建了一个Response对象，用来装HTML的，也放进箱子（Context）

第四，然后，ASP.NET说，太累了，这活儿没个干，还是雇个人吧。就雇了个项目经理（HttpApplication对象），然后就把箱子（Context）交给项目经理并且对它说，这里有我们收到的Request，你需要做的就是把里面的Reponse填一下，具体怎么干你掂量着吧，就走了。

这个项目经理（HttpApplication对象）就想啊，凭啥活儿我干钱你们拿啊？不行，我得找俩苦力去，于是就有了：程序员HttpModule和程序员HttpHandler，姑且就称他们为P_Module和P_Handler吧，项目经理先找到了P_Module.

P_Module(HttpModule)非常的能干，它能够去查看ASP.NET交给项目经理（HttpApplication对象）的箱子（Context），并且根据里面的东西做一些决定，比如安全啊（FormsAuthenticationModule),状态啊（SessionStateModule ）等等吧。在P_Module工作完成之后（也许已经改变了箱子里（Context）的内容），项目经理开始找P_Handler来做填充Response的工作。现在招人难啊，找了好久也没招到，好吧，找猎头（HttpHandler Factory）吧。猎头公司一看，“噢，要.aspx Handler啊",于是找来了一个天生就善于并且愿意处理页面的P_Handler（.aspx页面最终会编译成一个有继承机构的IHttpHander），然后交给项目经理（HttpApplication）。项目经理看了一眼P_Handler之后，觉得还行，就把P_Module处理过的箱子交给它并且说:"处理一下这个箱子里的东西，然后交给我"。

P_Handler是个天生的处理页面的牛人，它根据Request对象里的东西是用了一招"乾坤大挪移"，不知道怎么挪的，就挪出了HTML并塞进了Response对象中。P_Handler自信的笑了一声，把箱子交还给了项目经理（HttpApplication对象）。项目经理从箱子里面把Response对象拿出来直接给了IIS，IIS又给了你了，你就看到这篇文章了。

故事就是故事，故事就是故去的事，就是往事。那往事肯定就有遗漏的地方。那我们这个故事遗漏了哪些地方呢？

第一，IIS和ASP.NET之间的交互不是像我说的那么简单而直接的，中间还发生了很多事情。

第二，HttpModule，也就是我们的程序员P_Module, 它其实还能干很多事情，我们并没有去发掘。

第三，HttpHandler，也就是我们的程序员P_Handler，它的"乾坤大挪移"就是ProcessRequest方法，这里并没有详述到。

第四，。。。等我再想想再跟您聊。

希望这边小文能够帮助你更容易的理解ASP.NET生命周期，我会继续努力，争取以最简单明了的方式来speak out ASP.NET原理和运行机制。欢迎拍砖，谢谢。

本文链接

C#和sqlserver数字数据类型学习

2009-12-22T13:23:00Z

C#数字类型的数据包括decimal, double和 float。以前学过现在忘得都差不多了，现在简单的复习一下。根据MSDN的解释，decimal类型是128位的浮点数，数据范围是±1.0×10−28 to ±7.9×1028，精度在28-29位有效数字，在一个数字后面加m或M代表它是decimal类型。double类型是64位的浮点数，数据...