Flask中自定义红图拆分视图函数的方法以及——为什么蓝图不适合用于拆分试图函数

蓝图是模块级别的拆分，它不是设计来让你拆分试图函数的。要实现比模块级别下更具体的视图函数的拆分，例如在用Flask制作REST API时版本号下根据不同业务对象的函数拆分时，我们就需要自定义一个跟蓝图功能相同的模块。在这里，为了体现它跟蓝图的异曲同工之妙，我们将它命名为红图！

我们这里将示范上述场景中红图对象的制作。假设在v1版本的api中，有资源user, book等，我们希望对于每个资源对应的CURD方法分别放在各自的py文件中，如图所示：

我的文件结构是 app/api/v1/redpoint。

就像我们实例化蓝图对象一样，我们首先实例化我们的红图对象，虽然它暂时还未被定义，但我们会在后面补充它。我们分别在book.py和user.py里创建实例api：

# book.pyapi = Redprint('book')

# user.pyapi = Redprint('user')

对了，在使用我们的红图对象前别忘了先注册蓝图对象，因为我们同样需要将红图对象注册到蓝图上，就像蓝图注册到核心对象app上一样，在这里我就不演示在创建核心对象app工厂函数中注册蓝图的步骤了，但千万别忘了这一步哦。在蓝图v1/__init__.py中，在实例化蓝图对象后，注册红图：

from app.api.v1 import user, bookdef create_blueprint_v1():
bp_v1 = Blueprint(‘v1’,__name__)
user.api.register(bp_v1, url_prefix=’/user’) # 红图向蓝图的注册
book.api.register(bp_v1, url_prefix=’/book’)
return bp_v1

这个register方法将是我们稍后自定义的红图注册方法，它的实现方式主要参考蓝图的注册函数register_blueprint。

实现Redpoint

接下来我们便可以着手来编写Redpoint的具体实现方法了。试想一下，我们使用蓝图时都用到了哪些相关方法，除了上述的register，还有路由装饰器中的“.route”方法。我们定义：

class Redprint:def __init__(self, name):  self.name = namepassdef route(self):passdef register(self):pass

首先我们能想到的是，对于实例方法名字肯定是要传的。接下来怎么写呢？既然我们要参考蓝图的实现方式，那就Ctrl看看源码它对于接下来两个函数的实现，这是蓝图的route方法：

    def route(self, rule, **options):def decorator(f):endpoint = options.pop("endpoint", f.__name__)self.add_url_rule(rule, endpoint, f, **options)return freturn decorator

如果你对Flask的路由机制有所了解，你就知道它路由的实现其实就是内部调用了add_url_rule方法。它的参数”rule“就是我们装饰器中定义的url；就是我们定义的方法，也就是装饰器所作用的方法；endpoint照抄不误；**options是一系列关键字参数，例如methods。总的来说，route这个装饰器做的就是接收了一组参数并且调用了add_url_rule方法完成视图函数向蓝图的注册。我们要实现将红图的route代替蓝图的route，就需要在我们的Redprint里需要把我们的视图函数注册到蓝图里去，因为要传参f嘛，实现形式我们通过模仿蓝图得到：

class Redprint:def __init__(self, name):self.name = nameself.mound = []  # 把参数记录下来passdef route(self, endpoint, f, **options):def decorator(f):self.mound.append((f, rule, options))  # self是蓝图对象，以元组形式添加到列表中return freturn decoratordef register(self)pass

在蓝图的路由装饰器里，实例方法调用了本身的蓝图对象，我们红图里面又如何拿到蓝图对象呢？我们的思路是先把参数记录下来，在后面的代码编写里，总会有一个地方是可以遇到蓝图对象的。我们把这个记录存储在self.mound列表中，我们要添加到的列表中的元素有三个f、rule和options，这里用元组来概括它们。还有一点，这里self.mound为什么是列表呢，因为我们不仅仅需要保存一个视图函数的信息。

接着我们自己来实现红图的register方法：

def register(self, bp, url_prefix=None):if url_prefix is None:url_prefix = ‘/’ + self.namefor f, rule, options in self.mound:  # 将每个元组里的元素进行序列解包endpoint = options.pop(“endpoint”, f.__name__)bp.add_url_rule(url_prefix + rule, endpoint, f, **options)

该方法代替源代码中蓝图对象调用add_url_rule的注册方法。这里第一个参数是蓝图对象，第二个参数是url前缀，默认为None，在这个方法的中，我们能够得到蓝图对象，那么我们就可以在register方法里实现route装饰器的注册过程了。现在我们可以大胆放心的按照源码里的路由书写了。

options是一个字典，字典的pop()方法是取到某一个值并把原来字典里的值删除， f.__name__为它的默认值，因为options里并不一定有一个名为endpoint的键的值，当有endpoint时取endpoint的值，如果没有，取该函数的名字作为endpoint的名。

简化url结构

在下述app/api/v1/__init__.py定义蓝图bp_v1的这里，url_prefix显得颇为冗长。

from app.api.v1 import user, bookdef create_blueprint_v1():bp_v1 = Blueprint(‘v1’,__name__)user.api.register(bp_v1, url_prefix=’/user’) book.api.register(bp_v1, url_prefix=’/book’)return bp_v1

我们注册的红图对象名跟前缀名相同，我们决定把这两者结合一下以达到简洁的目的。在注册路由的方法里内部添加一个条件判断：

if url_prefix is None:url_prefix = ‘/’ + self.name

这样就可以去掉注册蓝图的url_prefix了。