当前位置:编程学习 > asp >>

Asp.Net MVC3 简单入门第一季(四)详解Request Processing Pipeline

引子

      很久没更新了,今天写点关于Asp.Net MVC的PipeLine。首先我们确认一点,Asp.Net WebFrom和Asp.Net MVC是在.Net平台下的两种web开发方式。其实他们都是基于Asp.Net Core的不同表现而已。看下面一张图,我们就能理解了WebForm和Asp.Net MVC的一个关系了。

\

那好我们了解了Asp.Net平台下的两种开发方式,相信大家对于WebForm的Pipeline都非常熟悉了,当然这也是你熟悉Asp.Net开发的必经之路。而看了很多关于Asp.Net MVC的资料很少有把整个Pipeline讲的非常清楚的。我暂时将自己浅陋的整理和理解总结如下,欢迎高手拍装!

第一阶段:客户端请求

客户端通过浏览器、其他软件、自己编写WebClinet、模拟HttpRequest等方法来请求一个URL。当然在Asp.Net WebFrom下,所有的请求都是归结到Handler上,普通的Aspx、Ascx等都是继承自IHttpHandler接口的一些实例,所以我总结出来:WebFrom下所有的请求都是请求的Handler【不考虑Url重写】。而做Asp.Net MVC的项目呢,所有的请求是都归结到Action上,Url应该是直接请求Action。

客户端发出请求后,此请求就会通过网络发出,可能经过多个路由、还可能经过域名解析等等....

最后可能请求的是一个集群IP,但是最终肯定只能由一台Web服务器的来处理此次请求。

第二阶段:IIS Web服务器

        当一个请求到达IIS服务器后,Windows系统的内核模块 HTTP.SYS就能监听到此次请求,并将此次请求的URL、IP以及端口等信息解析出来并将次请求交给注册的应用来处理:也就是IIS的站点。请求此时就到达了IIS,IIS【此处仅代表IIS6.0版本】就会去检查此次请求的URL的后缀并将相应的请求交给配置的处理后缀相应的isapi。如果是.aspx或者ascx等直接交给默认设置了此处理项的AspNet_isapi.dll来处理,如果我们想处理Asp.Net MVC的请求的话,我们需要在IIS里面设置处理*.*请求交给AspNet_isapi.dll来处理,才能将一个普通的MVC请求的URL:Http://localhost/DemoController/DemoAction交给AspNet_Isapi.dll来处理。

第三阶段:Asp.Net 运行时

此时请求到AspNet_Isapi.dll后,它负责启动Asp.Net RunTime【如过启动了,直接将请求交给RunTime】。Asp.Net 运行时此时会初始化一下HttpContext上下午,并从应用池中去取一个HttpApplication对象,并将HttpContext赋值给HttpApplication,此后HttpContext的信息就会一直在管道内往下传递。

HttpApplication对象开始初始化WebConfig文件中注册的IHttpModule,请求带着请求信息【HttpContext】随着管道流过多个HttpModule【一般可以做为权限校验、行为记录、日志等等,就是在到达Handler之前我们都可以直接处理此次Http请求,甚至可以重写URL】,当然也会经过我们注册的一些自定义的IHttpModule,在.Net 4.0的machine  的config文件中默认配置了一个URLRouteModule,这个也就是我们普通的Asp.Net MVC项目中的路由DLL引用【System.Web.Routing】内部的一个实现了IHttpModule接口的实现。请求最终流向了路由组件。

第四阶段:Routing组件

如果你用的是MVC 2+ .NET 3.5,则你会在你的web项目中发现UrlRoutingModule就配置在你的Web.Config。.NET 4却是在.Net的默认配置文件中配置的。

UrlRoutingModule做了这么几个工作:首先他会拿着你的请求到路由表中去匹配相应的路由规则。而路由表规则的定义是在HttpApplication初始化的时候由静态方法执行的,且看一个普通的Asp.Net MVC项目的Global.asax

	public class MvcApplication : System.Web.HttpApplication
    {
        public static void RegisterGlobalFilters(GlobalFilterCollection filters)
        {
            filters.Add(new HandleErrorAttribute());
        }
        public static void RegisterRoutes(RouteCollection routes)//定义路由表规则
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
            routes.MapRoute(
                "Default", // 路由名称
                "{controller}/{action}/{id}", // 带有参数的 URL
                new { controller = "Home", action = "Index", id = UrlParameter.Optional } // 参数默认值
            );
        }
        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            RegisterGlobalFilters(GlobalFilters.Filters);
            RegisterRoutes(RouteTable.Routes);//注册路由表
        }
    }


 

 而路由表的规则的注册是在 Application_Start() 方法内部,那此时请求在URLRouteModule内部到路由表中的所有规则进行匹配,并把匹配的Controller的信息和Action的信息以及RouteData等信息都解析处理,然后将请求进一步交给:实现了IRouteHandler【实现了IHttpHandler接口】 的一个实例,下面是IRouteHandler的源码:

	namespace System.Web.Routing
{  
    public interface IRouteHandler
    {       
        IHttpHandler GetHttpHandler(RequestContext requestContext);
    }
}

如果你想自己来实现这个接口然后在Web.Config中配置一下,那么请求就到了你自己的自定义的RouteHandler来执行后续的请求处理操作了。如果你使用的是默认的配置,那么请求会传递到MvcRouteHandler,那么请求f附加着HttpContext就会到达Asp.Net MVC的处理中了。

第五阶段:MvcRouteHandler创建Controller并调用其Excute方法

请求到此,其实跟WebForm都是一致的,而后面才出现了一些不同,此时请求才真正的进入System.Web.Mvc控制的领域内。后面所有的东西我们都可以直接通过源码来介绍了,而上面的所有的请求处理只能通过反射等方式来看或者学习,而后面的内容,我们可以幸福的直接看源码了。那就跟我走进它的管道怎么流动的吧...

接着上面讲,请求到了MvcRouteHandler类,而此类的源码如下:

	namespace System.Web.Mvc
{
    using System.Web.Routing;
    using System.Web.SessionState;
    public class MvcRouteHandler : IRouteHandler
    {
        private IControllerFactory _controllerFactory;
        public MvcRouteHandler()
        {
        }
        public MvcRouteHandler(IControllerFactory controllerFactory)
        {
            _controllerFactory = controllerFactory;
        }
        protected virtual IHttpHandler GetHttpHandler(RequestContext requestContext)//实现了IRouteHandler的方法,URLRouteModule调用
        {
            requestContext.HttpContext.SetSessionStateBehavior(GetSessionStateBehavior(requestContext));
            return new MvcHandler(requestContext);
        }
        .....
}

MvcRouteHandler的GetHttpHandler方法被URLRouteModule调用,而看上面的红色源码部分我们看到,它将请求上下文交给了MVCHandler,并返回了MVCHandler。

而我查看源码得知:MVCHandler实现了IHttpHandler,此时它的ProcessRequest方法被调用。且看MVCHandler的部分源代码:

	public class MvcHandler : IHttpAsyncHandler, IHttpHandler, IRequiresSessionState
 {
        protected internal virtual void ProcessRequest(HttpContextBase httpContext)
        {
            SecurityUtil.ProcessInApplicationTrust(() =>
            {
                IController controller;//在ProcessRequestInit方法中:controller = factory.CreateController(RequestContext, controllerName);//初始化
	IControllerFactory factory;//是由ProcessRequestInit方法中这行代码初始化的: factory = ControllerBuilder.GetControllerFactory();
	ProcessRequestInit(httpContext, out controller, out factory);//初始化了ControllerFactory
                try
                {
                    controller.Execute(RequestContext);
                }
                finally
                {
                    factory.ReleaseController(controller);
                }
            });
        }
}

从源码中我们得知:请求交给MVCHandler后,它首先从ControllerBuilder获取到当前的实现了IControllerFactory接口的ControllerFactory【也可以自己定义相关的CustomerControllerFactory,然后在Glable中注册使用】。然后根据上下文中请求的Controller的字符串信息创建出实现了IController接口的控制器。然后调用了上面代码中红色部分,也就是controller.Execute(RequestContext);

那此时请求就交给了controller。

CopyRight © 2012 站长网 编程知识问答 www.zzzyk.com All Rights Reserved
部份技术文章来自网络,