|
由于第一篇太长，本来应该放在第一篇的关于IIS7的知识被放在了第二篇，你可以结合第一篇，比较着IIS6来理解IIS7的改变。 在IIS7的集成管线模式中请求是如何被处理的 IIS7引入了一个激进的不同以前的管线模式，叫做集成管线模式，在这个模式中.NET是Web服务器本地支持的一部分。现在，IIS不再需要一个ISAPI扩展来激活.NET代码了——IIS7自己就可以搞定了，现在IIS7可以直接从.NET程序集中调用HTTP modules和HTTP handlers了。当然，如果你愿意的话，你仍然可以使用老的模式，依旧可以使用非托管的ISAPI扩展。 在IIS7中默认的模式是集成管线模式，但是如果你需要返回到传统的管线模式的话，是可以在应用程序池配置界面中对管线模式进行调整的。 说明：你可以在具体网站的高级设置中配置所使用的应用程序池。 Asp.net是如何被关联的 在集成管线模式中，IIS仍然根据URL文件扩展名来选择处理程序（ISAPI扩展或.NET IHttpHandler类或者HttpHandler工厂）。同样，你可以使用扩展名处理程序映射配置工具来配置扩展名和相应的处理程序。对ASP.NET请求来说不同的是，它不再需要通过aspnet_isapi.dll了——现在可以直接由IIS根据扩展名调用到相应的IHttpHandler处理程序了，比如默认的*.aspx到System.Web.UI.PageHandlerFactory。当你在服务器上开启ASP.NET服务的时候，所有的这些映射都已经自动设置好了。以前则是IIS根据扩展名把请求交给aspnet_isapi.dll，aspnet_isapi.dll再进一步根据扩展名甚至文件名把请求交给相应的IHttpHandler处理程序或者工厂的。 说明：该图显示的是传统模式下对应于*.aspx扩展名的配置，可以看出——传统模式下，具有*.aspx扩展名的URL是被IIS转交给aspnet_isapi.dll了的，aspnet_iaspi.dll后还有HttpRuntime，HttpModule，并最终到达System.Web.UI.PageHandlerFactory。//可以参考上一篇 集成管线模式是如何使得制造无后缀的URL变得如此Easy的 重述要点，一个IHttpHandler类负责终结处理一类请求，每一个请求只能被一个处理程序处理（根据请求URL的扩展名来决定被哪一个IHttpHandler类来处理）。相比之下，IHttpModule类是插入在处理请求的管线内的，并且你可以在单个请求的处理流程中插入任意多个此类的IHttpModule。在IIS7里，即使那些最终不是被ASP.NET处理的请求也是要经过这些注册了的IHttpModules的（不被ASP.NET处理的那些请求指的即是对非ASP.NET网站应用程序的请求，对静态文件的请求等此类请求）。//参考上一篇 因为UrlRoutingModule是一个注册了的IHttpModule（不是IHttpHandler），所以所有的请求都要经过它，请求需要经过管线中的IHttpModules是与URL扩展名和处理程序映射无关的事情。在UrlRoutingModule被调用的时候，它根据你的路由配置使路由系统尝试匹配进来的URL请求信息，如果匹配到了第一个入口，接着就会把控制权转交给你的一个controller类（或者一个自定义的IRouteHandler）。 UrlRoutingModule默认是被配置了的，因为当你创建一个新的空白的ASP.NET MVC网站应用程序的时候，你的web.config文件有一个<system.webServer>节点，如下： <system.webServer> <modules runAllManagedModulesForAllRequests="true"> <remove name="ScriptModule"/> <remove name="UrlRoutingModule"/> <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, ..."/> <add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, ... "/> </modules> </system.webServer> <system.webServer>节点是IIS7存取你的应用程配置数据的地方。所以，当你部署到IIS7的时候，无后缀URL再不需要任何其他手动设置的情况下即可工作了（如果一个无后缀的URL匹配了你的MVC路由配置的话，根据URL和匹配规则，controller和action即已经确定了。controller确定了，action确定了，再加上匹配的其他URL信息，包括QueryString，带着这些初始信息以及封装的请求上下文信息进入MVC框架，直到整个流程的完成都有源码供你阅读，因为ASP.NET MVC是开源的啊！赶快阅读它吧！另外微软开源的东西本来就少，并且从代码量上说ASP.NET MVC的规模刚好适合阅读，“它只有千余行核心代码//引用的老赵的话”相信你用几天的时间就可以搞通它了，并且相信你的收获会超出ASP.NET MVC本身之外。不阅读的人是傻瓜^_^）。嗯，现在我明白了为什么IIS7可以容易的制造出无后缀的URL了，你明白了吗？不失完整性，下面是关于Visual Studio 2008内置Web服务器的请求处理模式的。 在Visual Studio 2008的内置Web服务器中是如何处理请求的 你可能已经注意到了，当你在Visual Studio 2008的内置Web服务器中运行你的应用程序的时候，路由系统工作正常（Yes!无后缀！）。这是因为webdev.webserver.exe总是交由ASP.NET处理所有的请求，所以UrlRoutingModule总是被调用了。 但是，这可导致不愉快的事情发生，因为在我们随后将做好的Web应用程序部署到IIS6的时候事情变得复杂，发现事情并没有像在Visual Studio的集成Web服务器上那么简单。幸好，解决方案总是存在，下一遍一起学习。 说实话，要是仅仅是部署ASP.NET MVC应用程序的话，并没有那么复杂，无需长篇累牍的扯蛋。如果通过这些文字能够对初学者的知识起到编织作用从而有助于形成知识体系的话，目的已经达到了。 |
|
|
