博客园 - tmfc
uuid:6cbd1ba2-f883-4c34-aed1-30dde64a3a3e;id=721723
2009-03-15T05:54:41Z
tmfc
https://www.cnblogs.com/tmfc/
feed.cnblogs.com
https://www.cnblogs.com/tmfc/archive/2009/03/08/1406421.html
LightCloud设计特点 - tmfc
LightCloud使用一致性Hash算法(Consistent Hashing),好处就是当添加新节点的时候不用移动大量数据了。还不知道为什么?Consistent Hashing介绍。
一致性Hash算法也不算什么新鲜玩意儿了,凡是分布式系统都不免能见到它的身影,那LightCloud特别之处在哪里呢?
2009-03-08T12:32:00Z
2009-03-08T12:32:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】LightCloud使用一致性Hash算法(Consistent Hashing),好处就是当添加新节点的时候不用移动大量数据了。还不知道为什么?Consistent Hashing介绍。
一致性Hash算法也不算什么新鲜玩意儿了,凡是分布式系统都不免能见到它的身影,那LightCloud特别之处在哪里呢?
<a href="https://www.cnblogs.com/tmfc/archive/2009/03/08/1406421.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2009/03/08/1406355.html
有怪兽,有怪兽 - 通过MONSTER OF COMPRESSION选择压缩算法 - tmfc
2009年度的MONSTER OF COMPRESSION排名,提供了大量压缩工具(类库)的性能测试,可以通过榜单来找合适你的压缩算法。
2009-03-08T10:52:00Z
2009-03-08T10:52:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】2009年度的MONSTER OF COMPRESSION排名,提供了大量压缩工具(类库)的性能测试,可以通过榜单来找合适你的压缩算法。 <a href="https://www.cnblogs.com/tmfc/archive/2009/03/08/1406355.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2009/03/07/1405669.html
LightCloud -- 分布式键-值数据库 - tmfc
LightCloud是一个性能堪比Memcached的分布式的键-值数据库,但相对于易失的Memcached,它是持久化存储的,在传统的关系数据库之外提供了另一种选择。
2009-03-07T13:45:00Z
2009-03-07T13:45:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】LightCloud是一个性能堪比Memcached的分布式的键-值数据库,但相对于易失的Memcached,它是持久化存储的,在传统的关系数据库之外提供了另一种选择。 <a href="https://www.cnblogs.com/tmfc/archive/2009/03/07/1405669.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2008/07/29/1216384.html
[翻译]更有效的使用垃圾收集– 第一部分 - tmfc
翻译自Maoni's WebLog 文章Using GC Efficiently – Part 1,Maoni是微软CLR Performance组的成员
本文的目标是解释一些东西的代价好让你可以更好使用托管内存-而不是解释GC本身-只是解释如何使用它而已。我假设绝大多数人对于使用垃圾收集感兴趣,而不想自己实现一个。本文假设读者对GC有基础的了解,如果你需要一些关于GC的背景知识,Jeff Richter写了两篇非常好的MSDN文章,1和2。
首先我会关注工作站级类型的GC(Wks GC),然后我会解释服务器类型的GC(Svr GC)与前者的区别和你该用哪个(但是通常情况下你不需要选择,而我也会解释为什么你不需要)。
2008-07-29T05:53:00Z
2008-07-29T05:53:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】翻译自Maoni's WebLog 文章Using GC Efficiently – Part 1,Maoni是微软CLR Performance组的成员
本文的目标是解释一些东西的代价好让你可以更好使用托管内存-而不是解释GC本身-只是解释如何使用它而已。我假设绝大多数人对于使用垃圾收集感兴趣,而不想自己实现一个。本文假设读者对GC有基础的了解,如果你需要一些关于GC的背景知识,Jeff Richter写了两篇非常好的MSDN文章,1和2。
首先我会关注工作站级类型的GC(Wks GC),然后我会解释服务器类型的GC(Svr GC)与前者的区别和你该用哪个(但是通常情况下你不需要选择,而我也会解释为什么你不需要)。
<a href="https://www.cnblogs.com/tmfc/archive/2008/07/29/1216384.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/12/25/603413.html
企业架构应用模式读书笔记(四) - tmfc
Web展现
最近几年企业应用中最大的改变无疑是基于Web浏览器的用户界面的崛起。优势在于:不需要部署任何客户端软件,一致的UI使用方法,便利的全球访问。
通常Web服务器上有着各种各样的配置文件来确定哪些URL该由那个程序处理,一个Web服务器可以支持多种程序。它的工作只是解释请求(request)的URL并把控制交给服务器端程序。
服务器端程序基本上可以分为两种基本的类型:script和server page
2006-12-25T12:55:00Z
2006-12-25T12:55:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】Web展现
最近几年企业应用中最大的改变无疑是基于Web浏览器的用户界面的崛起。优势在于:不需要部署任何客户端软件,一致的UI使用方法,便利的全球访问。
通常Web服务器上有着各种各样的配置文件来确定哪些URL该由那个程序处理,一个Web服务器可以支持多种程序。它的工作只是解释请求(request)的URL并把控制交给服务器端程序。
服务器端程序基本上可以分为两种基本的类型:script和server page <a href="https://www.cnblogs.com/tmfc/archive/2006/12/25/603413.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/12/19/597154.html
企业架构应用模式读书笔记(三)下 - tmfc
结构映射模式
当人们谈论对象-关系映射时,大部分的人都是在讨论结构映射模式,大部分模式都和Table Data Gateway无关,某些可以用在Row Data Gateway或Active Record上,大部分都需要用在Data Mapper上。
映射关系
关键点是联系对象和关系的不同的方法,这会引出两个问题。第一个问题在表现(representation)上,对象保持引用而关系数据库保持的是键的关联。第二个问题是,对象可以很容易的使用集合来保持多个与它有关的其他对象的引用,但是关系数据库却正好相反,相关对象会有一个到主对象的反向的引用。比如一个部门有多个员工,部门对象持有多个员工的引用,但是再关系数据库中,每个员工的数据行中会有一个到部门表的外键连接,而不是在部门表中引用多个员工(因为关系数据库不支持这样做)。
解决表现问题的方法是在对象中保持一个Identity Field,使用它来作为关系数据库的键。当你访问数据库中的外键时,你使用的是Foreign Key Mapping来连接适当的对象间的连接。如果你没有在Identit
2006-12-19T11:54:00Z
2006-12-19T11:54:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】结构映射模式
当人们谈论对象-关系映射时,大部分的人都是在讨论结构映射模式,大部分模式都和Table Data Gateway无关,某些可以用在Row Data Gateway或Active Record上,大部分都需要用在Data Mapper上。
映射关系
关键点是联系对象和关系的不同的方法,这会引出两个问题。第一个问题在表现(representation)上,对象保持引用而关系数据库保持的是键的关联。第二个问题是,对象可以很容易的使用集合来保持多个与它有关的其他对象的引用,但是关系数据库却正好相反,相关对象会有一个到主对象的反向的引用。比如一个部门有多个员工,部门对象持有多个员工的引用,但是再关系数据库中,每个员工的数据行中会有一个到部门表的外键连接,而不是在部门表中引用多个员工(因为关系数据库不支持这样做)。
解决表现问题的方法是在对象中保持一个Identity Field,使用它来作为关系数据库的键。当你访问数据库中的外键时,你使用的是Foreign Key Mapping来连接适当的对象间的连接。如果你没有在Identit <a href="https://www.cnblogs.com/tmfc/archive/2006/12/19/597154.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/12/18/596130.html
企业架构应用模式读书笔记(三)上 - tmfc
架构模式
架构模式的选择对后续的程序开发有着深远的影响并且难以切换(难以从一种模式重构到另一种),所以必须仔细的选择架构模式。
将SQL语句嵌在逻辑代码中会显得非常的丑陋,DBA也希望能够通过了解SQL语句来决定怎样对数据库进行索引,所有这一切的原因让我们倾向于将访问数据库的SQL语句从领域逻辑中分离出来。
以数据表结构来组织类的结构是一个好主意,这样类和数据表可以一一对应。这些类组成了一个数据表的Gateway,Gateway主要分为两种,Row Data Gateway和Table Data Gateway。
Row Data Gateway中,数据表中的每一行对应于一个对象实例,比较自然的符合了面向对象的思想。
Table Data Gateway中,整个数据表只需要一个对应的对象实例。而用来储存数据的则是Record Set,一个通用的数据结构,适合于任何一张表。
2006-12-18T12:29:00Z
2006-12-18T12:29:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】架构模式
架构模式的选择对后续的程序开发有着深远的影响并且难以切换(难以从一种模式重构到另一种),所以必须仔细的选择架构模式。
将SQL语句嵌在逻辑代码中会显得非常的丑陋,DBA也希望能够通过了解SQL语句来决定怎样对数据库进行索引,所有这一切的原因让我们倾向于将访问数据库的SQL语句从领域逻辑中分离出来。
以数据表结构来组织类的结构是一个好主意,这样类和数据表可以一一对应。这些类组成了一个数据表的Gateway,Gateway主要分为两种,Row Data Gateway和Table Data Gateway。
Row Data Gateway中,数据表中的每一行对应于一个对象实例,比较自然的符合了面向对象的思想。
Table Data Gateway中,整个数据表只需要一个对应的对象实例。而用来储存数据的则是Record Set,一个通用的数据结构,适合于任何一张表。 <a href="https://www.cnblogs.com/tmfc/archive/2006/12/18/596130.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/10/10/525391.html
企业应用架构模式读书笔记(二) - tmfc
三个主要的模式:Transaction Script,Domain Model,Table Model
最简单的方法是使用Transaction Script,Transaction Script本质上就是从表现层接受输入,进行验证和计算,保存进数据库,调用其他外部操作并且返回更多的信息,帮助计算并组织数据给表现层的过程。基本上就是将用户可能做的事情组织成一个个的函数,所以可以将其想象成动作的脚本,或者一个个事务。
Transaction Script的优势:
是几乎每个开发者都了解的简单的过程模式
配合使用简单的数据库层模式,如Row Data Gateway,Table Data Gateway时工作的很好
非常明显的边界:以打开事务开始,关闭事务结束。
但是,在领域逻辑变得越来越复杂时,Transaction Script也会有很多劣势,会出现很多难以消除的重复代码,子方法越来越多后,缺乏清晰的结构。
这个时候,就该以面向对象方式处理逻辑的Domain Model模式登场了。我们主
2006-10-10T09:09:00Z
2006-10-10T09:09:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】三个主要的模式:Transaction Script,Domain Model,Table Model
最简单的方法是使用Transaction Script,Transaction Script本质上就是从表现层接受输入,进行验证和计算,保存进数据库,调用其他外部操作并且返回更多的信息,帮助计算并组织数据给表现层的过程。基本上就是将用户可能做的事情组织成一个个的函数,所以可以将其想象成动作的脚本,或者一个个事务。
Transaction Script的优势:
是几乎每个开发者都了解的简单的过程模式
配合使用简单的数据库层模式,如Row Data Gateway,Table Data Gateway时工作的很好
非常明显的边界:以打开事务开始,关闭事务结束。
但是,在领域逻辑变得越来越复杂时,Transaction Script也会有很多劣势,会出现很多难以消除的重复代码,子方法越来越多后,缺乏清晰的结构。
这个时候,就该以面向对象方式处理逻辑的Domain Model模式登场了。我们主 <a href="https://www.cnblogs.com/tmfc/archive/2006/10/10/525391.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/26/515587.html
企业应用架构模式读书笔记(一) - tmfc
分层是用来分割复杂软件系统的最常用手段之一。如:操作系统建立在设备驱动和CPU指令上;FTP建立在TCP层之上,TCP建立在IP层上,IP建立在以太网上。
把分层结构想像成蛋糕,每一层都建立在它下一层上。意味着上层使用下层的服务,但是对更底层的服务一无所知。如,第四层使用第三层定义的服务,第三层使用第二层的服务,但是第四层并不了解第二层的服务。
分层的优势:
可以单独了解一层的东西,而不用管其他层
可以替换某一层的实现
最小化层之间的依赖
为建立标准做好准备
一个低层可以被很多高层使用(提高复用率)
分层的劣势:
分层对部分东西,而不是全部东西,有一个良好的封装。有时会引起连锁的更改,如,为了在用户界面上多显示一个属性,必须更改从数据库到UI之间的所有层。
额外的层会降低性能
2006-09-26T13:33:00Z
2006-09-26T13:33:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】分层是用来分割复杂软件系统的最常用手段之一。如:操作系统建立在设备驱动和CPU指令上;FTP建立在TCP层之上,TCP建立在IP层上,IP建立在以太网上。
把分层结构想像成蛋糕,每一层都建立在它下一层上。意味着上层使用下层的服务,但是对更底层的服务一无所知。如,第四层使用第三层定义的服务,第三层使用第二层的服务,但是第四层并不了解第二层的服务。
分层的优势:
可以单独了解一层的东西,而不用管其他层
可以替换某一层的实现
最小化层之间的依赖
为建立标准做好准备
一个低层可以被很多高层使用(提高复用率)
分层的劣势:
分层对部分东西,而不是全部东西,有一个良好的封装。有时会引起连锁的更改,如,为了在用户界面上多显示一个属性,必须更改从数据库到UI之间的所有层。
额外的层会降低性能
<a href="https://www.cnblogs.com/tmfc/archive/2006/09/26/515587.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/18/507264.html
对[解耦的故事]的一些补充 - tmfc
我的前两篇blog原意是想通过一个故事说明委托的来龙去脉,但是后来的主题却变成了解耦的一些方法介绍,对于委托本身的关注反而少了,加上编故事的水平不高,有点虎头蛇尾的感觉,大家见谅,以后有机会再来好好整理以下。 在网上找几篇好文来补充一下委托的内容: 台湾msdn的大内高手专栏,蔡学镛先生的好文(繁体+台湾术语,希望大家看得懂): 函数指针进化论(上) 函数指针进化论(下)
2006-09-18T03:45:00Z
2006-09-18T03:45:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】我的前两篇blog原意是想通过一个故事说明委托的来龙去脉,但是后来的主题却变成了解耦的一些方法介绍,对于委托本身的关注反而少了,加上编故事的水平不高,有点虎头蛇尾的感觉,大家见谅,以后有机会再来好好整理以下。 在网上找几篇好文来补充一下委托的内容: 台湾msdn的大内高手专栏,蔡学镛先生的好文(繁体+台湾术语,希望大家看得懂): 函数指针进化论(上) 函数指针进化论(下) <a href="https://www.cnblogs.com/tmfc/archive/2006/09/18/507264.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/18/506848.html
解耦的故事(二)-松耦合时代的来临 - tmfc
什么?!更改接口? 随着时间的流逝,市面上开始布满了使用tmfc的开关的产品,看着自己的产品受到大家如此热烈的欢迎,tmfc感到无比的满足。但是他还是发现有些产品没有使用他的开关,他感到纳闷,“为什么你们不在这个台灯上装开关呢?”他指着装有老式插口(可以把两根电线的其中一根更换插槽来实现不同功能的控制装置,在开关发明之前统治着这个紧耦合的世界)的台灯向厂家的促销员问道。“您有所不知啊!说起...
2006-09-18T03:30:00Z
2006-09-18T03:30:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】什么?!更改接口? 随着时间的流逝,市面上开始布满了使用tmfc的开关的产品,看着自己的产品受到大家如此热烈的欢迎,tmfc感到无比的满足。但是他还是发现有些产品没有使用他的开关,他感到纳闷,“为什么你们不在这个台灯上装开关呢?”他指着装有老式插口(可以把两根电线的其中一根更换插槽来实现不同功能的控制装置,在开关发明之前统治着这个紧耦合的世界)的台灯向厂家的促销员问道。“您有所不知啊!说起... <a href="https://www.cnblogs.com/tmfc/archive/2006/09/18/506848.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/10/500379.html
解耦的故事(一)-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();
}
}
2006-09-10T12:25:00Z
2006-09-10T12:25:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】开关的诞生 话说在一个紧耦合的世界,有一个名为tmfc的工匠,一天,他发明了一个叫做开关的的设备。他琢磨了老半天,决定把开关装在自己的床头,这样他就不用在睡前起床去拔电灯的电线了(这可是个紧耦合的世界啊),tmfc对自己的发明非常满意。
class Switch{
Light light;
public void Switch(Light l){
light = l;
}
public void TurnOn(){
light.On();
}
public void TurnOff(){
light.Off();
}
}
<a href="https://www.cnblogs.com/tmfc/archive/2006/09/10/500379.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/04/493327.html
[翻译]了解ASP.NET底层架构系列文章(包括Word下载) - tmfc
[翻译]了解ASP.NET底层架构(一) [翻译]了解ASP.NET底层架构(二) [翻译]了解ASP.NET底层架构(三) [翻译]了解ASP.NET底层架构(四) [翻译]了解ASP.NET底层架构(五) [翻译]了解ASP.NET底层架构(六) [翻译]了解ASP.NET底层架构(七) [翻译]了解ASP.NET底层架构(八) [翻译]了解ASP.NET底层架构(完) 完整Word文档下载[...
2006-09-04T05:37:00Z
2006-09-04T05:37:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】[翻译]了解ASP.NET底层架构(一) [翻译]了解ASP.NET底层架构(二) [翻译]了解ASP.NET底层架构(三) [翻译]了解ASP.NET底层架构(四) [翻译]了解ASP.NET底层架构(五) [翻译]了解ASP.NET底层架构(六) [翻译]了解ASP.NET底层架构(七) [翻译]了解ASP.NET底层架构(八) [翻译]了解ASP.NET底层架构(完) 完整Word文档下载[... <a href="https://www.cnblogs.com/tmfc/archive/2006/09/04/493327.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/04/493323.html
[翻译]了解ASP.NET底层架构(完) - tmfc
唷-我们已经走完了整个请求处理过程了.这过程中有很多底层的信息,我对HTTP模块和HTTP处理器是怎么工作的并没有描述的非常详细.挖掘这些信息相当的费时间,我希望在了解了ASP.NET底层机制后,你能获得和我一样的满足感.
在结束之前让我们快速的回顾一下我在本文中讨论的从IIS到处理器(handler)的过程中,事件发生的顺序
IIS获得请求
检查脚本映射中,此请求是否映射到aspnet_isapi.dll
启动工作进程 (IIS5中为aspnet_wp.exe,IIS6中为w3wp.exe)
.NET运行时被载入
2006-09-04T01:00:00Z
2006-09-04T01:00:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】唷-我们已经走完了整个请求处理过程了.这过程中有很多底层的信息,我对HTTP模块和HTTP处理器是怎么工作的并没有描述的非常详细.挖掘这些信息相当的费时间,我希望在了解了ASP.NET底层机制后,你能获得和我一样的满足感.
在结束之前让我们快速的回顾一下我在本文中讨论的从IIS到处理器(handler)的过程中,事件发生的顺序
IIS获得请求
检查脚本映射中,此请求是否映射到aspnet_isapi.dll
启动工作进程 (IIS5中为aspnet_wp.exe,IIS6中为w3wp.exe)
.NET运行时被载入
<a href="https://www.cnblogs.com/tmfc/archive/2006/09/04/493323.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/04/493304.html
[翻译]了解ASP.NET底层架构(八) - tmfc
HttpHandlers
模块是相当底层的,而且对每个来到ASP.NET应用程序的请求都会被触发.Http处理器更加的专注并处理映射到这个处理器上的请求.
Http处理器需要实现的东西非常简单,但是通过访问HttpContext对象它可以变得非常强大.Http处理器通过实现一个非常简单的IHttpHandler接口(或是它的异步版本,IHttpAsyncHandler),这个接口甚至只含有一个方法-ProcessRequest()-和一个属性IsReusable.关键部分是ProcessRequest(),这个函数获取一个HttpContext对象的实例作为参数.这个函数负责从头到尾处理Web请求.
单独的,简单的函数?太简单了,对吧?好的,简单的接口,但并不弱小!记住WebForm和WebService都是作为Http处理器实现的,所以在这个看上去简单的接口中包装了很强大的能力.关键是这样一个事实,当一个请求来到Http处理器时,所有的ASP.NET的内部对象都被准备和设置好来处理请求了.主要的是HttpContext对象,提供所
2006-09-04T00:59:00Z
2006-09-04T00:59:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】HttpHandlers
模块是相当底层的,而且对每个来到ASP.NET应用程序的请求都会被触发.Http处理器更加的专注并处理映射到这个处理器上的请求.
Http处理器需要实现的东西非常简单,但是通过访问HttpContext对象它可以变得非常强大.Http处理器通过实现一个非常简单的IHttpHandler接口(或是它的异步版本,IHttpAsyncHandler),这个接口甚至只含有一个方法-ProcessRequest()-和一个属性IsReusable.关键部分是ProcessRequest(),这个函数获取一个HttpContext对象的实例作为参数.这个函数负责从头到尾处理Web请求.
单独的,简单的函数?太简单了,对吧?好的,简单的接口,但并不弱小!记住WebForm和WebService都是作为Http处理器实现的,所以在这个看上去简单的接口中包装了很强大的能力.关键是这样一个事实,当一个请求来到Http处理器时,所有的ASP.NET的内部对象都被准备和设置好来处理请求了.主要的是HttpContext对象,提供所 <a href="https://www.cnblogs.com/tmfc/archive/2006/09/04/493304.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/03/493241.html
[翻译]了解ASP.NET底层架构(七) - tmfc
“流过”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
2006-09-03T01:37:00Z
2006-09-03T01:37:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】“流过”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 <a href="https://www.cnblogs.com/tmfc/archive/2006/09/03/493241.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/02/492938.html
[翻译]了解ASP.NET底层架构(六) - tmfc
HttpRuntime,HttpContext和HttpApplication
当一个请求到来时,它被路由到ISAPIRuntime.ProcessRequest()方法.这个方法调用HttpRuntime.ProcessRequest方法,它作一些重要的事情(用Reflector查看System.Web.HttpRuntime.ProcessRequestInternal方法):
为请求创建一个新的HttpContext实例
获取一个HttpApplication实例
调用HttpApplication.Init()方法来设置管道的事件
Init()方法触发开始ASP.NET管道处理的HttpApplication.ResumeProcessing()方法
2006-09-02T13:22:00Z
2006-09-02T13:22:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】HttpRuntime,HttpContext和HttpApplication
当一个请求到来时,它被路由到ISAPIRuntime.ProcessRequest()方法.这个方法调用HttpRuntime.ProcessRequest方法,它作一些重要的事情(用Reflector查看System.Web.HttpRuntime.ProcessRequestInternal方法):
为请求创建一个新的HttpContext实例
获取一个HttpApplication实例
调用HttpApplication.Init()方法来设置管道的事件
Init()方法触发开始ASP.NET管道处理的HttpApplication.ResumeProcessing()方法
<a href="https://www.cnblogs.com/tmfc/archive/2006/09/02/492938.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/09/01/491668.html
[翻译]了解ASP.NET底层架构(五) - tmfc
回到运行时
在这里我们有一个在ISAPI扩展中活动的,可调用的ISAPIRuntime对象的实例.每当运行时是启动的并运行时,ISAPI的代码调用ISAPIRuntime.ProcessRequest()方法,这个方法是真正的进入ASP.NET管道的入口.这个流程在图4中显示.
记住ISAPI是多线程的,所以请求也会通过AppDomainFactory.Create()(译注:原文为ApplicationDomainFactory,疑有误)函数中返回的引用在多线程环境中被处理.列表1显示了ISAPIRuntime.ProcessRequest()方法中反编译后的代码,这个方法接收一个ISAPI ecb对象和服务类型(WorkerRequestType)作为参数.这个方法是线程安全的,所以多个ISAPI线程可以同时在这一个被返回的对象实例上安全的调用这个方法.
2006-09-01T01:27:00Z
2006-09-01T01:27:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】回到运行时
在这里我们有一个在ISAPI扩展中活动的,可调用的ISAPIRuntime对象的实例.每当运行时是启动的并运行时,ISAPI的代码调用ISAPIRuntime.ProcessRequest()方法,这个方法是真正的进入ASP.NET管道的入口.这个流程在图4中显示.
记住ISAPI是多线程的,所以请求也会通过AppDomainFactory.Create()(译注:原文为ApplicationDomainFactory,疑有误)函数中返回的引用在多线程环境中被处理.列表1显示了ISAPIRuntime.ProcessRequest()方法中反编译后的代码,这个方法接收一个ISAPI ecb对象和服务类型(WorkerRequestType)作为参数.这个方法是线程安全的,所以多个ISAPI线程可以同时在这一个被返回的对象实例上安全的调用这个方法.
<a href="https://www.cnblogs.com/tmfc/archive/2006/09/01/491668.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/08/31/491663.html
[翻译]了解ASP.NET底层架构(四) - tmfc
进入.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的一个预定的接口.图
2006-08-31T12:45:00Z
2006-08-31T12:45:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】进入.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的一个预定的接口.图 <a href="https://www.cnblogs.com/tmfc/archive/2006/08/31/491663.html" target="_blank">阅读全文</a>
https://www.cnblogs.com/tmfc/archive/2006/08/31/490755.html
[翻译]了解ASP.NET底层架构(三) - tmfc
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的请求都会通过命名管道调用被路由到这个进程来.
2006-08-31T01:19:00Z
2006-08-31T01:19:00Z
tmfc
https://www.cnblogs.com/tmfc/
【摘要】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的请求都会通过命名管道调用被路由到这个进程来.
<a href="https://www.cnblogs.com/tmfc/archive/2006/08/31/490755.html" target="_blank">阅读全文</a>