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, includefrom app02 import viewsurlpatterns = [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 = Noneif isinstance(arg, tuple):# Callable returning a namespace hint.try:urlconf_module, app_name = argexcept 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 = argif 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 = Noneurlconf_module = argif 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_namereturn (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 Viewif isinstance(view, (list, tuple)):# For include(...) processing.pattern = Pattern(route, is_endpoint=False)urlconf_module, app_name, namespace = viewreturn 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 Viewpattern = RoutePattern('blog/', is_endpoint=False)urlconf_module, app_name, namespace = importlib.import_module('app02.urls'), None, Nonereturn 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 objecttried = []match = self.pattern.match(path)if match:new_path, args, kwargs = matchfor 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 submatchsub_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.argsif not sub_match_dict:sub_match_args = args + sub_match.argscurrent_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 viewsfrom 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 URLResolverurlpatterns = [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 urlsNone,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. 最后

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