Django学习之十一：真正理解Django的路由分发和反解url原理

佚名 5年前 (2019-01-30) Python 2019人围观抢沙发百度已收录

URL Dispatcher

URL Dispatcher

简介

django的url dispatcher 设计是基于一个url mapper来工作的。
这个url mapper主要用在两个方向：

SRE实战互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。

url 匹配到视图
通过提供的标识，反解出url

Django provides a solution such that the URL mapper is the only repository of the URL design. You feed it with your URLconf and then it can be used in both directions:
** Starting with a URL requested by the user/browser, it calls the right Django view providing any arguments it might need with their values as extracted from the URL.
** Starting with the identification of the corresponding Django view plus the values of arguments that would be passed to it, obtain the associated URL.

模式概念

Django的URL 模式非常的清晰和优雅。一个高质量的web应用就需要一个好的URL模式。
Django的URL 助记点：

依照MVC模式，通过url 分发到对应的 view视图
将 url 和 view视图都封装到了URLPattern对象，统称url对象
url对象放到urlpattern列表中
urlpattern列表单独放在一个module中，我们叫url module。一般命名上都叫urls.py
每一个django项目，都有一个唯一的叫root_urlconf的url module.这个ROOT_URLCONF时可以配置的放在项目的settings.py中。指定模块路径相对于项目的python path 路径字符串即可，如'luffyapi.urls'
也可以通过中间件对HTTPRequest对象添加一个属性叫urlconf,赋值指定url module，这样就会使用HttpRequest.urlconf 作为root_urlconf，针对当前request的生命周期。
中间件还是什么时候初始化加载url module
按着列表顺序，第一个匹配到的就停止匹配了。然后import and call view
url对象不仅提供通过url匹配拿到view，还提供通过名称拿到url字符串，这就是所谓的反解析url。反解url主要用在重定向响应或者html模板中。还有就是model object定义一个get_absolute_url（）对象方法中。
url对象名称，通过url对象实例化参数中指定，re_path(r'test',test_view, name='testurl')'
还有一个 URLResolver对象，这个对象是urlpattern对象的容器。且URLResolver对象可以嵌套，也就是URLResolver对象看成URLPattern和URLResolver的容器，容器中放置一个URLResolver对象，就是路由的嵌套，也就是子路由。最顶层有一个URLResolver对象，即顶层容器。
无论URLPattern对象还是URLResolver对象，都是通过re_path()或者path()得到的。
为了提供效率切不浪费内存空间，每个URLPattern的url正则表达式都是第一次访问时才会编译（python中有正则表达式对象，放于内存中）
判断实例化为URLResolver对象还是URLPattern对象，根据re_path()或者path（）的第二个参数的类型。如果时list或者tuple则实例化为URLResolver对象。如果是callable就实例化为URLPattern对象。
所以利用子路由来减少过多url相同前缀的冗余，时最佳实践。就在前面也所过了，子路由也是有URLResolver对象。所以要通过re_path等来实例化出一个子路由，就得完成一个子路由的构建过程。子路由构建过程具体看本文下面。
现在说回url对象反解获取url字符串的功能
对url对象进行命名，提供实例化时的name参数
django-app-namespace, 源码中叫 app_name
由于django项目中，app时可插拔可复用的，所以对同一个app的多次使用，就要通过对其进行区别，所以提出了app instance的概念，通过不同子路由方式来逻辑划分同一个app的场景下，提出了instance namespace。在源码中就叫 namesapce
通过app_name 和 namespace 都可以作为反解url的一个参数
查看from django.urls import reverse 的源码，理解怎么利用 name/app_name/namespcae反解出url对象的实际url字符串的。
反解url还要提供args 或者kwargs 参数。

对比URLPattern 与 URLResolver (多态的体现)

通过对比两个类的定义：

看到，urlresolver也有resovle解析方法。只不过urlresolver的解析会再去加载子url module模块中的urlpatterns列表。然后再对列表中的进行循环匹配过程，一直嵌套下去，知道最后的return跳出返回一个ResolverMatch对象。而urlpattern的resolver直接就返回ResovlerMatch对象了。只不过前者会有重新加载获取子url module模块来获取urlpatterns的逻辑。

两个类都用同名的方法，只是表现出来的的状态有所不同。这就是面向对象多态在代码中的体现。提供相同的对外接口，展现出来的状态过程有所不同，最后返回相同的对象。

构建子路由几种方式

子路由除了减少路由前缀的冗余，还可以满足多种url前缀使用同一app的业务场景。

方式一

参照源码，从最low-level源码层面的方式,参照实例化出URLResolver对象的源码

if isinstance(view, (list, tuple)):  # 这里的view是re_path或path的第二个参数
    # For include(...) processing.
    pattern = Pattern(route, is_endpoint=False)
    urlconf_module, app_name, namespace = view
    return URLResolver(
        pattern,
        urlconf_module,
        kwargs,
        app_name=app_name,
        namespace=namespace,
    )

从源码可以看出，如果view参数是一个列表或元组类型，那么将会实例化出URLResolver对象，并且对view参数要有且有三个元素。第一个元素可以是子路由的模块的python path 也可以直接是 url对象的列表（查看URLResolver.url_patterns源码可以理解）；第二个元素和第三个元素都可以空，也可以都有，但是不能只有namespace单独有。

方式二

django内置的from django.urls import include 提供生成第一种方式view参数的函数

include源码：

def include(arg, namespace=None):
    app_name = None
    if isinstance(arg, tuple):
        # Callable returning a namespace hint.
        try:
            urlconf_module, app_name = arg
        except ValueError:
            if namespace:
                raise ImproperlyConfigured(
                    'Cannot override the namespace for a dynamic module that '
                    'provides a namespace.'
                )
            raise ImproperlyConfigured(
                'Passing a %d-tuple to include() is not supported. Pass a '
                '2-tuple containing the list of patterns and app_name, and '
                'provide the namespace argument to include() instead.' % len(arg)
            )
    else:
        # No namespace hint - use manually provided namespace.
        urlconf_module = arg

    if isinstance(urlconf_module, str):
        urlconf_module = import_module(urlconf_module)
    patterns = getattr(urlconf_module, 'urlpatterns', urlconf_module)
    app_name = getattr(urlconf_module, 'app_name', app_name)
    if namespace and not app_name:
        raise ImproperlyConfigured(
            'Specifying a namespace in include() without providing an app_name '
            'is not supported. Set the app_name attribute in the included '
            'module, or pass a 2-tuple containing the list of patterns and '
            'app_name instead.',
        )
    namespace = namespace or app_name
    # Make sure the patterns can be iterated through (without this, some
    # testcases will break).
    if isinstance(patterns, (list, tuple)):
        for url_pattern in patterns:
            pattern = getattr(url_pattern, 'pattern', None)
            if isinstance(pattern, LocalePrefixPattern):
                raise ImproperlyConfigured(
                    'Using i18n_patterns in an included URLconf is not allowed.'
                )
    return (urlconf_module, app_name, namespace)

可以看到提供app_name 而不提供namespace的话是会抛出异常的。

Notice：关于app_name 与 namespace 存在这样一个依赖逻辑：

提供了app_name，可以不提供namesapce
提供了namespace，就必须提供app_name
两者都提供
两者都不提供
意思就是有namespace必须有app_name.
为什么要有这样的逻辑？
因为这和反解url 算法逻辑有关。看下面说明有关算法逻辑

inlucde()的参数方式，也有几种：

include('luffyapi.urls') # app_name 可能来自'luffyapi.urls.app_name' ，这里没提供namespace，所以'luffyapi.urls'中不能有app_name.'
include(('luffyapi.urls', 'luffyapi')) # app_name 可能被'luffyapi.urls.app_name' 覆盖
include(('luffyapi.urls', 'luffyapi'), namespace='luffyapiuser'）
include('luffyapi.urls', namespace='luffyapiuser') # 这种方式在'luffyapi.urls' 中就必须有app_name。

反解url算法逻辑

参考官方文档和from django.urls import reverse 函数的源码。大致可以这样理解：

首先，如果reverse或者 url tag(in Template file) 中，只是提供了'name' url对象实例化是的name参数，那么反解逻辑很简单.直接循环一个记录字典中找到。对于name相同的，只会取出在urlpattern列表中最后一个。
如果，提供的反解名字是'namespace:name' 这种模式，逻辑就变得复杂了。
1.1 首先将namespace 作为一个app_name 查找，会yield 返回这个app_name 的所有instance的列表。
1.2 然后django会找寻与app_name名字相同的instance namespace作为用于解析name的对象。。
1.3 如果没有，django会使用最后部署的instance作为解析name的对象。
1.4 如果列表中一个都没匹配上app_name，那么django会直接通过instanc namespace去查找。
1.5 最后，如果reverse带入了current_app 参数指定当前的app ,那么就使用当前的URLResolver来解析name。最后这一点有点不好理解特别是在使用reverse与 url tag 上。