Django路由分发的三种方式以及命名空间namespce—

1. 前言

2. include常规路由分发

3. include源码解析

4. 路由分发的第二种写法

5. 路由分发的第三种写法

6. 小结

7. 有关namespace

8. 最后

1. 前言

本篇文章主要是讲解路由分发的三种方式。当然，你可能在想，一般做路由分发只需要一个include就能搞定，为什么还有另外三种方式呢。

这个就要追溯到Django的底层源码了，通过研究Django中include的底层源码了，从而发现另外两种作路由分发的方式。

2. include常规路由分发

在了解include方法之前，我们应该了解什么是路由分发：

路由分发：传入的HTTP请求映射到相应的视图函数或处理程序的过程。通过前缀匹配，将url分发到相应的app里面，在对相应的app里面的url路由进行再一次匹配。

通俗来讲，就是我们在app里面单独定义url，通过全局的前缀匹配之后，再去相应的app里面进行路由匹配

inlcude方法，常用于作路由分发 ，可以将剩下的路由交给app去匹配：

urls.py

urlpatterns = [
    path('blog/', include('app02.urls')),
]

app02.urls.py

from django.contrib import admin
from django.urls import path, re_path, include

from app02 import views

urlpatterns = [
    path('', views.test, name='index'),
    path('<int:post_id>/', views.test, name='detail'),
]

然后我们在进行匹配的时候，就需要先匹配前缀，再匹配后面的：

我们在访问具体url的时候，就需要先进行前缀blog匹配，然后再进入到app02里面进行匹配。

3. include源码解析

path('blog/', include('app02.urls')),

我们对当前这条代码进行解析，以下是inlcude的源码：

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)

其中ags就是我们传递进来的路径字符串

这里，主要是判断是否是元组，我们传递进来的是字符串，所以可以先忽略这里

其中，最重要的就是patterns和app_name

这都是通过反射getattr从上面导入进来的模块里面拿的数据，也就是app02里面的urls里面的urlpatterns

这里，主要是跟命名空间相关的：

定义namespace后，就需要定义好app_name

命名空间在后面聊

其实最后，总结下来，也就这些内容：

def include(arg = 'app02.urls', namespace=None):
    app_name = None
    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)
    namespace = namespace or app_name
    return (urlconf_module, app_name, namespace)

返回的是一个元组：

urlconf_module：导入的模块（app02.urls）

app_name：app02下的app名字，与命名空间相挂钩

```
namespace：命名空间
```

4. 路由分发的第二种写法

所以，通过源码，我们得出了路由分发的第二种写法：

path('blog/', (importlib.import_module('app02.urls'), None, None))

其中第一个就是以上的通过动态导入的字符串路径，第二个和第三个都是与命名空间相关的

5. 路由分发的第三种写法

我们先看一下_path的源码：

def _path(route, view, kwargs=None, name=None, Pattern=None):
    from django.views import View

    if isinstance(view, (list, tuple)):
        # 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,
        )
    elif callable(view):
        pattern = Pattern(route, name=name, is_endpoint=True)
        return URLPattern(pattern, view, kwargs, name)
    elif isinstance(view, View):
        view_cls_name = view.__class__.__name__
        raise TypeError(
            f"view must be a callable, pass {view_cls_name}.as_view(), not "
            f"{view_cls_name}()."
        )
    else:
        raise TypeError(
            "view must be a callable or a list/tuple in the case of include()."
        )

很显然，我们第二个view参数传递的是一个元组，因此走的就是第一条路：

最后返回的就是一个URLResolver对象，常规的是返回一个URLPattern对象

我们稍微做一下整理：

def _path('blog/', (importlib.import_module('app02.urls'), None, None) ):
    from django.views import View

    pattern = RoutePattern('blog/', is_endpoint=False)
    urlconf_module, app_name, namespace = importlib.import_module('app02.urls'), None, None
    return URLResolver(
        RoutePattern('blog/', is_endpoint=False),
        importlib.import_module('app02.urls'),
        None,
        app_name=None,
        namespace=None,
    )

实际上，最后就是一个URLResolver的对象。

现在，我们来看URLResolver的reslove函数（如果不清楚为什么看这个的，我们看我以前的一篇文章，就是关于路由匹配源码的解析）：

    def resolve(self, path):
        path = str(path)  # path may be a reverse_lazy object
        tried = []
        match = self.pattern.match(path)
        if match:
            new_path, args, kwargs = match
            for pattern in self.url_patterns:
                try:
                    sub_match = pattern.resolve(new_path)
                except Resolver404 as e:
                    self._extend_tried(tried, pattern, e.args[0].get("tried"))
                else:
                    if sub_match:
                        # Merge captured arguments in match with submatch
                        sub_match_dict = {**kwargs, **self.default_kwargs}
                        # Update the sub_match_dict with the kwargs from the sub_match.
                        sub_match_dict.update(sub_match.kwargs)
                        # If there are *any* named groups, ignore all non-named groups.
                        # Otherwise, pass all non-named arguments as positional
                        # arguments.
                        sub_match_args = sub_match.args
                        if not sub_match_dict:
                            sub_match_args = args + sub_match.args
                        current_route = (
                            ""
                            if isinstance(pattern, URLPattern)
                            else str(pattern.pattern)
                        )
                        self._extend_tried(tried, pattern, sub_match.tried)
                        return ResolverMatch(
                            sub_match.func,
                            sub_match_args,
                            sub_match_dict,
                            sub_match.url_name,
                            [self.app_name] + sub_match.app_names,
                            [self.namespace] + sub_match.namespaces,
                            self._join_route(current_route, sub_match.route),
                            tried,
                            captured_kwargs=sub_match.captured_kwargs,
                            extra_kwargs={
                                **self.default_kwargs,
                                **sub_match.extra_kwargs,
                            },
                        )
                    tried.append([pattern])
            raise Resolver404({"tried": tried, "path": new_path})
        raise Resolver404({"path": path})

我们看到这一句：

这就相当于遍历了urls里面的整个url_patterns：

这里的self.url_patterns其实是一个方法，它被赋予@cached_property装饰器，代表不需要加上括号，就能执行：

@cached_property：这个函数与property()类似，但增加了缓存，可以直接通过方法名来访问方法，不需要在方法名后添加一对“（）”小括号。

重点看以下两句，返回的其实就是app02.urls下面的url_patterns

由此，我们引出来第三种编写路由分发的方法：

# 最初
path('web/', (
    [
        path('v1/', www_views.login, name='v1'),
        path('v2/', www_views.login, name='v2'),
    ], 
    None, 
    None)
)

# 解析之后
URLResolver(
    RoutePattern('api/',name=None,is_endpoint=False),
	[
        path('v1/', www_views.login, name='v1'),
        path('v2/', www_views.login, name='v2'),
    ], 
    None,
    app_name=None,
    namespace=None
)

6. 小结

对于常规的path对象，它的底层是URLPattern类，但是对于路由分发，它的底层就是URLResolver对象了。

from django.urls import path, re_path, include
from apps.www import views

from django.urls import URLPattern, ResolverMatch
from django.urls.resolvers import RoutePattern
from importlib import import_module
from apps.www import views as www_views
from django.urls.resolvers import URLResolver

urlpatterns = [
    URLPattern(
        RoutePattern("login/", name=None, is_endpoint=True),
        views.login,
        None,
        None
    ),
    URLResolver(
        RoutePattern('api/', name=None, is_endpoint=False),
        import_module("apps.base.urls"),  # 模块对象 from app.base import urls
        None,
        app_name=None,
        namespace=None
    ),
    URLResolver(
        RoutePattern('web/', name=None, is_endpoint=False),
        [
            path('v1/', www_views.login, name='v1'),
            path('v2/', www_views.login, name='v2'),
        ],
        None,
        app_name=None,
        namespace=None
    )
]

7. 有关namespace

平常做路由的时候，我们有一个参数为name ，主要就是为URL取的别名，在后续操作中更加方便引入该路径：

path('user/', views.User.as_view() , name='user')

但是在做路由分发的时候，涉及到一个命名空间，也就是涉及到相同的name，但是无法去做解析识别。

比如我现在有两个app：app01和app02

以下是两个单独的urls

可以看到，两个里面都有name，并且name都是一样的。

如果，这个时候我要来做反向解析:通过name生成url：

可以看到，最后解析出来的是blog2 ，为什么是blog2呢，这是因为相同的name，第二个把第一个给覆盖了。

这个时候，命名空间的作用就来了，可以很好的做分割：

设置namespace

path('blog/', include('app02.urls', namespace='v1')),
path('blog2/', include('app01.urls', namespace='v2'))

设置app_name ，使namespace能够找到对应的app

ok，设置好之后，我们再一次进行匹配：

这个时候，我们需要在解析之前加上一个命名空间：

ok，现在就能找到相应的URL啦

8. 最后

路由分发，常规用法是会比较简单的，但是要搞清楚源码的执行流程，还需要花费一定时间和精力，不懂的小伙伴，可以去看看我之前写过的路由定义和路由匹配的源码分析，本篇文章只做了一些简单的介绍。