IIS 与ASPNET（）
ASPNET集成
从上面对IIS x和IIS 的介绍中我们不难发现IIS与ASPNET是两个相互独立的管道（Pipeline）在各自管辖范围内它们各自具有自己的一套机制对HTTP请求进行处理两个管道通过ISAPI实现连通IIS是第一道屏障当对HTTP请求进行必要的前期处理（比如身份验证等）时通过ISAPI将请求分发给ASPNET管道当ASPNET在自身管道范围内完成对HTTP请求的处理时处理后的结果再返回到IISIIS对其进行后期处理（比如日志记录压缩等）最终生成HTTP响应图反映了IIS 与ASPNET之间的桥接关系
图 基于IIS 与ASPNET双管道设计
从另一个角度讲IIS运行在非托管的环境中而ASPNET管道则是托管的ISAPI还是连接非托管环境和托管环境的纽带IIS x和IIS 把两个管道进行隔离至少带来了下面的一些局限与不足
相同操作的重复执行IIS与ASPNET之间具有一些重复的操作比如身份验证
动态文件与静态文件处理的不一致因为只有基于ASPNET动态文件（比如aspxasmxsvc等）的HTTP请求才能通过ASPNET ISAPI进入ASPNET管道而对于一些静态文件（比如htmlxmlimg等）的请求则由IIS直接响应那么ASPNET管道中的一些功能将不能用于这些基于静态文件的请求比如我们希望通过Forms认证应用于基于图片文件的请求就做不到
IIS难以扩展对于IIS的扩展基本上就体现在自定义ISAPI但是对于大部分人来说这不是一件容易的事情因为ISAPI是基于Win的非托管的API并非一种面向应用的编程接口通常我们希望的是诸如定义ASPNET的HttpModule和HttpHandler一样通过托管代码的方式来扩展IIS
对于Windows平台下的IIS来讲ASPNET无疑是一等公民它们之间不应该是井水不犯河水而应该是你中有我我中有你的关系为此在IIS 中实现了两者的集成通过集成可以获得如下的好处
允许通过本地代码（Native Code）和托管代码（Managed Code）两种方式定义IIS Module这些IIS Module注册到IIS中形成一个通用的请求处理管道由这些IIS Module组成的这个管道能够处理所有的请求不论请求基于怎样的资源类型比如可以将FormsAuthenticationModule提供的Forms认证应用到基于aspxCGI和静态文件的请求
将ASPNET提供的一些强大的功能应用到原来难以企及的地方比如将ASPNET的URL重写功能置于身份验证之前
采用相同的方式去实现配置检测和支持一些服务器特性（Feature）比如ModuleHandler映射定制错误配置（Custom Error Configuration）等
图演示了在ASPNET集成模式下IIS整个请求处理管道的结构可以看到原来ASPNET提供的托管组件可以直接应用在IIS管道中
图 基于IIS 与ASPNET集成管道设计
返回目录ASPNET MVC 框架揭秘
编辑推荐
ASP NET开发培训视频教程
Microsoft NET框架程序设计视频教程
Java程序性能优化让你的Java程序更快更稳定
Visual C++音频/视频技术开发与实战
