前言
项目地址:https://github.com/SEN-Wanted/BackEnd
blueprint作为可以将应用模块化的一个很有用的方式,大型的应用几乎所有都会采用这种模式,而在一些小项目的开发上面是否有必要采用这种模式来进行开发呢?我的意见是如果是对于团队协作的项目,最好是一开始就采用blueprint这种开发方式,以这次的项目为例(预期实现一个点餐app后端,项目较小),起初的文件架构如下:
Appserver/
├── App
│ ├── static/ # 静态资源文件夹
│ ├── templates/ # 模板文件夹
│ ├── __init__.py
│ └── view.py # 主文件,未使用blueprint
├── run.py
├── config.py # 配置文件
├── requirements # 需求文件
└── README.md
起初是没什么问题,但是当多人协作时,每个人虽然负责不同的部分编写,但是却在同一个文件下编写(view.py),造成的问题是在更新文件的时候忽视别人的提交,可能会覆盖他人的代码,这是我们决定使用蓝图(blueprint)来解决这个问题,每个人只需专注于自己负责的代码文件,使用后文件组织形式如下:
Appserver/
├── app
│ ├── static/ # 静态资源文件夹
│ ├── templates/ # 模板文件夹
│ ├── json_test/ # 用来存放测试文件
│ ├── __init__.py # 初始化文件
│ ├── store_info.py # blueprint
│ ├── user_info.py # blueprint
│ ├── order_info.py # blueprint
│ ├── store_by_id.py # blueprint
│ ├── orders_by_user_id.py # blueprint
│ ├── type_search.py # blueprint
│ ├── user_login.py # blueprint
│ ├── models.py # 数据格式
│ ├── createdb.py # 创建数据库
│ └── view.py # 调用blueprint
├── config.py # 配置文件
├── run.py # 主程序文件
├── requirements # 需求文件
└── README.md
虽然文件结构变复杂了,但是有两点好处是我切身体会到的:
1.维护方便
2.添加需求方便
blueprint的使用还是挺简单方便的,以如下文件结构为例:
Appserver/
├── app
│ ├── static/ # 静态资源文件夹
│ ├── templates/ # 模板文件夹
│ ├── __init__.py # 初始化文件
│ └── test_blueprint.py # blueprint
└── run.py
1.声明blueprint
简单来说就是声明一个变量为blueprint,同时给它一个唯一的__name__
,完成之后,我们就可以在view.py中对它进行使用
test_blueprint.py
# -*- coding: utf-8 -*-
from flask import Blueprint, request
test_blueprint = Blueprint('fir_blueprint',__name__)
@test_blueprint.route('/test', methods=['GET'])
def test():
return "test success"
2.使用blueprint
在声明blueprint之后,需要在_init_ .py中进行注册
_init_.py
# -*- coding: utf-8 -*-
from flask import Flask
from test_blueprint import test_blueprint
app = Flask(__name__)
app.register_blueprint(test_blueprint)
其他文件:
run.py
# -*- coding: UTF-8 -*-
from app import app
if __name__ == '__main__':
'''
开启 debug模式
# 设置 host='0.0.0.0'
'''
app.run(debug=True, host='0.0.0.0')
在Appserver目录下运行run.py,之后在浏览器中访问http://0.0.0.0:5000/test就可以看到返回的成功信息"test success"