Django中间件加载原理
假设我们有如下中间件:
setting.py文件
MIDDLEWARE = [
    'django.middleware.A',
    'django.middleware.B',
    'django.middleware.C',
    'django.middleware.D',
]
Django中间件的五个方法调用顺序如下:
process_request(request)process_view(request, view_func, args, kwargs)- if has exception  
process_exception(request, e) 
- if has exception  
 process_template_response(request, response)- if has exception  
process_exception(request, e) 
- if has exception  
 
process_response(request, response)
需要注意的是,process_response之前的4个方法中返回了任何的HTTPResponse对象,都不会触发process_response。
Django的中间件都必须继承MiddlewareMixin类
class MiddlewareMixin:
    def __init__(self, get_response=None):
        self.get_response = get_response
        super().__init__()
    def __call__(self, request):
        response = None
        if hasattr(self, 'process_request'):
            response = self.process_request(request)
        if not response:
            response = self.get_response(request)
        if hasattr(self, 'process_response'):
            response = self.process_response(request, response)
        return response
父类的__call__()方法中只处理了中间件的process_request和process_response这个两个一头一尾的方法,中间的几个方法其实都封装在了get_response这个变量中。
在Django启动时会初始化WSGIHandler类,会把A,B,C,D四个中间件的对象实例化出来
class WSGIHandler(base.BaseHandler):
	...
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        # 加载中间件实例到内存中,此时中间件实例的各种方法已经被包裹在 _get_response() 方法的前后了
        self.load_middleware()
	# __call__方法会在一个新的子线程中被调用
    def __call__(self, environ, start_response):
		...
        request = self.request_class(environ)
		# get_response是父类的方法,调用此方法触发self._middleware_chain()的递归调用
        response = self.get_response(request)
		..
        return response
中间件的加载由父类BaseHandler的load_middleware()方法实现
首先看load_middleware()方法:
class BaseHandler:
	...
    def load_middleware(self):
        self._request_middleware = []
        self._view_middleware = []
        self._template_response_middleware = []
        self._response_middleware = []
        self._exception_middleware = []
        # 这里可以直接把handler看做是self._get_response方法
        handler = convert_exception_to_response(self._get_response)
        # 通过for循环,按照逆序依次实例化要加载的中间件
        for middleware_path in reversed(settings.MIDDLEWARE):
            # 通过中间件的类全命加载他们的类对象
            middleware = import_string(middleware_path)
            try:
                # 然后把handler作为参数,实例化中间件
                mw_instance = middleware(handler)
            except MiddlewareNotUsed as exc:
                if settings.DEBUG:
                    if str(exc):
                        logger.debug('MiddlewareNotUsed(%r): %s', middleware_path, exc)
                    else:
                        logger.debug('MiddlewareNotUsed: %r', middleware_path)
                continue
            if mw_instance is None:
                raise ImproperlyConfigured(
                    'Middleware factory %s returned None.' % middleware_path
                )
            # 把含有'process_view'方法的中间件对象放入到self._view_middleware列表[]中
            if hasattr(mw_instance, 'process_view'):
                self._view_middleware.insert(0, mw_instance.process_view)
            # 把含有'process_template_response'方法的中间件对象放入到self._template_response_middleware列表[]中
            if hasattr(mw_instance, 'process_template_response'):
                self._template_response_middleware.append(mw_instance.process_template_response)
            # 把含有'process_exception'方法的中间件对象放入到self._exception_middleware列表[]中
            if hasattr(mw_instance, 'process_exception'):
                self._exception_middleware.append(mw_instance.process_exception)
            # 这里的hanler可以直接看做是mw_instance,即一个中间件实例对象
            handler = convert_exception_to_response(mw_instance)
        # We only assign to this when initialization is complete as it is used
        # as a flag for initialization being complete.
        # 循环结束时handler是第一个中间件实例对象A(B(C(D(_get_response))))
        self._middleware_chain = handler
可以从for循环开始分析,看看A,B,C,D这4个中间件时如何被实例化加载到内存中的
第一次:
handler = _get_response- 实例化中间件
D(handler) - 依次查看D中是否有
process_view,process_exception,process_template_response有就放入响应的列表中去。 - 赋值 
handler = D(_get_response) 
第二次:
handler = D(_get_response)- 实例化中间件
C(handler) - 依次查看C中是否有
process_view,process_exception,process_template_response有就放入响应的列表中去。 - 赋值 
handler = C(D(_get_response)) 
第三次:
handler = C(D(_get_response))- 实例化中间件
B(handler) - 依次查看B中是否有
process_view,process_exception,process_template_response有就放入响应的列表中去。 - 赋值 
handler = B(C(D(_get_response))) 
第四次:
handler = B(C(D(_get_response)))- 实例化中间件
A(handler) - 依次查看A中是否有
process_view,process_exception,process_template_response有就放入响应的列表中去。 - 赋值 
handler = A(B(C(D(_get_response)))) 
到此为止for循环结束,handler = A(B(C(D(_get_response)))),也就是这四个中间件的实例都加载到内存了,同时把他们的process_view,process_exception, process_template_response这3个方法分别放到了对应的3个列表中。最后self._middleware_chain = handler,也就是把handler赋值给了WSGIHandler对象的实例属性self._middleware_chain。然后self._middleware_chain会在BaseHandler的get_response方法中被调用。
class BaseHandler:
    def get_response(self, request):
        set_urlconf(settings.ROOT_URLCONF)
        # 此函数完成对中间件的各个函数调用已经视图函数的调用
        # 首先依次调用中间件A,B,C,D的process_request
        # 之后调用_get_respones()方法,_get_respones()方法又会调用在load_middleware()方法中从中间件中添加的process_view函数,
        # process_template_response和 process_exception函数
        # 最后依次调用中间件的process_response方法
        response = self._middleware_chain(request)
        response._closable_objects.append(request)
		...
        return response
    def _get_response(self, request):
        ...
        return response
self._middleware_chain(request)被调用时,即A(B(C(D(_get_response))))(request)
- A-CALL-1 
response = A.process_request(request) - A-CALL-2 response is None, 
response = B(C(D(_get_response)))(request)- B-CALL-1 
response = B.process_request(request) - B-CALL-2 response is None, 
response = C(D(_get_response))(request)- C-CALL-1 
response = C.process_request(request) - C-CALL-2 response is None, 
response = D(_get_response)(request)- D-CALL-1 response = 
D.process_request(request) - D-CALL-2 response is None, 
response = _get_response(request) - D-CALL-3 response is not None 
response = D.process_response(request, response)retrun C-CALL-2 
 - D-CALL-1 response = 
 - C- CALL-3 response is not None, 
response = C.process_response(request, response)retrun B-CALL-2 
 - C-CALL-1 
 - B-CALL-3 response is not None, 
response = B.process_response(request, response)retrun A-CALL-2 
 - B-CALL-1 
 - A-CALL-3 response is not None, 
response = A.process_response(request, response)retrun response 
MiddlewareMixin的__call__方法中分为三步:
response = self.process_request(request)response = self.get_response(request)response = self.process_response(request, response)
最后 return response
解释下这个调用层级图:
A-CALL-1: 代表执行 中间件A实例对象的__call__的第一步
A-CALL-2: 代表执行 中间件A实例对象的__call__的第二步
A-CALL-3: 代表执行 中间件A实例对象的__call__的第三步
最终_get_response函数在被调用前依次会调用A,B,C,D的process_request方法,然后再执行_get_response函数,最后再依次调用它们的process_response方法。
在D-CALL-2 response is None, response = _get_response(request)这一步中,会调用_get_response方法,我们再来看一下这个方法:
class BaseHandler:
	    def _get_response(self, request):
	        # 调用视图函数和process_view函数, process_exception函数,process_template_response函数
	        response = None
			...
			# 1. 找通过url匹配找到视图函数callback
	        resolver_match = resolver.resolve(request.path_info)
	        callback, callback_args, callback_kwargs = resolver_match
			...
	        # 2. 调用_view_middleware列表中的所有中间件的proces_view
	        for middleware_method in self._view_middleware:
	            response = middleware_method(request, callback, callback_args, callback_kwargs)
	            if response:
	                break
			# 3. 调用视图函数
	        if response is None:
	            wrapped_callback = self.make_view_atomic(callback)
	            try:
	                response = wrapped_callback(request, *callback_args, **callback_kwargs)
	            except Exception as e:
	                response = self.process_exception_by_middleware(e, request)
			...
	        # 4. 调用_template_response_middleware列表中保存的中间件的process__template_response方法,如果有异常则会调用_exception_middleware列表中的process_exception方法
	        elif hasattr(response, 'render') and callable(response.render):
	            for middleware_method in self._template_response_middleware:
	                response = middleware_method(request, response)
	                # Complain if the template response middleware returned None (a common error).
	                if response is None:
	                    raise ValueError(
	                        "%s.process_template_response didn't return an "
	                        "HttpResponse object. It returned None instead."
	                        % (middleware_method.__self__.__class__.__name__)
	                    )
	            try:
	                response = response.render()
	            except Exception as e:
	                response = self.process_exception_by_middleware(e, request)
	        return response
这个方法的主要逻辑:
找通过url匹配找到视图函数
callback调用
_view_middleware列表中的所有中间件的proces_view调用视图函数
callback调用
_template_response_middleware列表中保存的中间件的process__template_response方法,如果有异常则会调用_exception_middleware列表中的process_exception方法
总结
通过继承MiddlewareMixin类的__call__方法实现了一种类似递归的调用。
Django中间件加载原理的更多相关文章
- iOS 下拉刷新-上拉加载原理
		
前言 讲下拉刷新及上拉加载之前先给大家解释UIScrollView的几个属性 contentSize是UIScrollView可以滚动的区域. contentOfinset 苹果官方文档的解释是&qu ...
 - 老调重弹:JDBC系列之<驱动加载原理全面解析) ----转
		
最近在研究Mybatis框架,由于该框架基于JDBC,想要很好地理解和学习Mybatis,必须要对JDBC有较深入的了解.所以便把JDBC 这个东东翻出来,好好总结一番,作为自己的笔记,也是给读者 ...
 - composer 实现自动加载原理
		
简介 一般在框架中都会用到composer工具,用它来管理依赖.其中composer有类的自动加载机制,可以加载composer下载的库中的所有的类文件.那么composer的自动加载机制是怎么实现的 ...
 - Vue(基础七)_webpack(webpack异步加载原理)
		
---恢复内容开始--- 一.前言 1.webpack异步加载原理’ 2.webpack.ensure原理 ...
 - 深入解析 composer 的自动加载原理 (转)
		
深入解析 composer 的自动加载原理 转自:https://segmentfault.com/a/1190000014948542 前言 PHP 自5.3的版本之后,已经重焕新生,命名空间.性状 ...
 - 解析苹果的官方例子LazyTableImages实现图片懒加载原理
		
解析苹果的官方例子LazyTableImages实现图片懒加载原理 首先在官网下载源码: https://developer.apple.com/library/ios/navigation/#sec ...
 - Spring Boot源码分析-配置文件加载原理
		
在Spring Boot源码分析-启动过程中我们进行了启动源码的分析,大致了解了整个Spring Boot的启动过程,具体细节这里不再赘述,感兴趣的同学可以自行阅读.今天让我们继续阅读源码,了解配置文 ...
 - AMD-require.js模块加载原理
		
项目中使用大了require.js,功能实现,现重新学习下模块加载原理相关知识,借鉴如下博文:https://blog.csdn.net/ai52011/article/details/7711361 ...
 - 从SpringBoot源码分析 配置文件的加载原理和优先级
		
本文从SpringBoot源码分析 配置文件的加载原理和配置文件的优先级 跟入源码之前,先提一个问题: SpringBoot 既可以加载指定目录下的配置文件获取配置项,也可以通过启动参数( ...
 
随机推荐
- 字符串匹配:从机器到后缀自己主动KMP
			
后缀自己主动机(sam)对字符串匹配 ==== 我们已经配置了一个相对较短的模式字符串sam. 为P="abcabcacab", T[1..i]后缀.因此,它是sam最长前缀长度: ...
 - VC实现程序重启的做法
			
作者:朱金灿 来源:http://blog.csdn.net/clever101 很多时候系统有很多配置项,修改了配置项之后能有一个按钮实现系统重启.所谓重启就是杀死系统的当前进程,然后重新开一个新进 ...
 - SAAS是否能实现人在家工作的梦想?
			
在过去的十年,在人们的工作环境的巨大变化已经发生,越来越多的人选择在家工作. 高租金的办公室,络,快速宽带的广泛应用.这些因素都使得远程办公成为了人们工作中密不可分的一种方式.使用普通手机和办公操作系 ...
 - 许多其他C++的class样本
			
class A{ public: A(){}//构造函数,作用分配类所需的空间 }; int main() { A a; } a它是类A示例! 版权声明:本文博客原创文章.博客,未经同意,不得转 ...
 - Unity3D它Button包
			
原来难,转载请注明切换: http://blog.csdn.net/u012413679/article/details/26354715 ---- kosion 这里如果,你己经配置好了Unity3 ...
 - .NET中System.Diagnostics.Stopwatch、System.Timers.Timer、System.Threading.Timer 的区别
			
1.System.Diagnostics.Stopwatch Stopwatch 实例可以测量一个时间间隔的运行时间,也可以测量多个时间间隔的总运行时间. 在典型的 Stopwatch 方案中,先调用 ...
 - 元素命名空间中的“MvcBuildViews”无效
			
原文:元素命名空间中的"MvcBuildViews"无效 症状描述: VS2010打开项目时提示:"元素 命名空间"http://schemas.microso ...
 - 『SHELL』--SHELL脚本执行方式(转)
			
Shell脚本的执行方式: 注明:wd代表“脚本保存的目录” 1.fork 语法:/wd/shell.sh fork是最普通的, 就是直接在脚本里面用/wd/shell.sh来调用shell.sh这个 ...
 - WCF研究-后篇
			
最后就对之前的资料进行整理以及在其他博客园的朋友那看到的资料稍微分享一下,这样有助于学习和使用WCF的朋友更好的学习和理解WCF 后期要是看到合适的资料也会再次编辑这个后篇,让我共同进步! 后篇 1. ...
 - QThread的源码(直接搜索"thread.cpp"即可,或者在github里搜)
			
void QThread::run() { (void) exec(); } int QThread::exec() { Q_D(QThread); QMutexLocker locker(& ...