​

首先，蓝图通俗理解就是对于视图方法模块化的一个很好的工具
一、先来看一下没使用蓝图中的视图方法

#views.py
 1 from app import app
 2 
 3 
 4 @app.route('/user/index')
 5 def index():
 6     return 'user_index'
 7 
 8 @app.route('/user/show')
 9 def show():
10     return 'user_show'
11 
12 @app.route('/user/add')
13 def add():
14     return 'user_add'
15 
16 @app.route('/admin/index')
17 def adminindex():
18     return 'admin_index'
19 
20 @app.route('/admin/show')
21 def adminshow():
22     return 'admin_show'
23 
24 @app.route('/admin/add')
25 def adminadd():
26     return 'admin_add'

#从视图中可以看到admin、user两个用户的三个方法

这样写肯定是没问题的，一个方法一个视图，但是这样就不是违背的python模块化和代码优美的初衷了嘛，当然我还是要考虑以下几点问题的

一、如果admin和user两个用户不止三个功能而是几百个功能，导致代码也有几万行？
二、如果是大型项目所有的功能都是分不同模块和开发人员开发，都在一个views.py里堆代码，导致提交冲突怎么办
三、如果以后没有了damin和user两个用户模块了，我还要一行一行删除相互功能的代码，岂不是很low

所以为了解决以上的矛盾，就有了蓝图这个工具：blueprint

什么是蓝图？
一个蓝图用于定义的单个应用的视图与静态资源等等
什么时候用蓝图？
蓝图最大的凶器就是把不同的应用拆分成不同的组件，把user和adim拆分不同的主键这样就方便多了
代码上！！

#admin.py
from flask import Blueprint,render_template, request

admin = Blueprint('admin',__name__)

@admin.route('/index')
def index():
    return render_template('admin/index.html')

@admin.route('/add')
def add():
    return 'admin_add'

@admin.route('/show')
def show():
    return 'admin_show'

 

#user.py
from flask import Blueprint, render_template, redirect

user = Blueprint('user',__name__)

@user.route('/index')
def index():
    return render_template('user/index.html')

@user.route('/add')
def add():
    return 'user_add'

@user.route('/show')
def show():
    return 'user_show'

把视图中的两个应用分别用蓝图拆分成两个不同的.py文件，是不是方便多了
最后在看一下views.py中的代码

from app import app
from .admin import admin
from .user import user
#这里分别给app注册了两个蓝图admin,user
#参数url_prefix='/xxx'的意思是设置request.url中的url前缀，
#即当request.url是以/admin或者/user的情况下才会通过注册的蓝图的视图方法处理请求并返回
app.register_blueprint(admin,url_prefix='/admin')
app.register_blueprint(user, url_prefix='/user')

在这里就不难看出蓝图对于稍微大点的项目的重要地位的