flask 不适宜工程项目,彻底只关注目录构造,不顾及外挂等

无需加好友免费技术支持

很多人都觉得 flask 不适宜工程项目，实际上这是不对的，flask 不但做小众网址强，

做知名网站并不逊色。较好的目录构造对于整个新项目拥有深刻的影响，特别是对

维护保养开发者，阅读文章友善，查看改动便捷。

注：这儿所提到的是否合适工程项目，彻底只关注目录构造，不顾及外挂等，

拒绝接受键盘侠辩驳

看看我的目录构造：

简短说说每一个模块功效

myblog(项目名)底下 app, logs, migrations, venv 四个文件夹或控制模块

app 以下属于按功能模块划分的，如article与文章内容有关的功能，auth 登录认证有关功能，comment是有关的留言功能等logs 是工程项目的日志文档migrations 与数据库系统迁移相关venv 工程项目的虚拟器manager.py 是当前用以开发设计调节的一个项目通道，之后维护保养一个wsgi.py 便捷用gunicorn近期的启动管理可能会对目录构造得到更好的设计方案。假如我们把目录功能拆得如此细，那样新项目

是如何串联起来的？这也是重要。

蓝图

实际上，蓝图是联接每一个功能控制模块的前提条件。最先，在功能控制模块中建立蓝图

再对这一蓝图目标articles_bp 在app上进行申请

这时候有人会说，假如有好几个控制模块，每次都会修改application.py中的

configure_blueprint函数，比较麻烦。有没有简单的方式？其实有回答

自己写一个完成自动注册的功能。能通过 importlib.import_module去进行

动态性导进控制模块，我们自己的蓝图目标了解标准，统一取名XXX开始或末尾，再通过

要实现自动注册功能，剖析该控制模块是否存在蓝图目标。这里不赘述了。

通过以上实际操作 ，我们将要每一个功能控制模块串连在一起。

日志

日志配备也非常重要。一个好的日志对精准定位有很大帮助。

我在这所使用的日志策略是按日区划，每天一个日志， 一个月内默认设置储存日志，

一起来看看编码。

数据库系统迁移

庆幸的是，人们总是期待布署能简易，大家找到数据库系统迁移工具箱flask_migrate, 应用很简单。

flask db init # 复位专用工具，生成一个migrations文件夹

flask db migrate # 生成迁移文档，即生成迁移文档migrations下边的version文件夹中文件

那些文档是实际实行动作命令，如创建表格、类似性等

flask db upgrade # 实行数据库操作实际是实行上图upgrade()函数公式，

操作数据库， 比如说图中有一个create_table 你能了解这是一个创建表格动作。

实行结束后，能够查验数据库系统是不是生成此表。

但是，实际上，我们通常和睦flask_script比如：

应用指令随之改成图中注解所显示。

数据信息迁移坑

最开始应用数据库连接mysql pymysql 那样，但是也会有一个warning

心里不开心，经过一番检索，找到回答，成了 mysql mysqlconnector这类

方法，果真没报warning，心里开心。

之后在开展数据信息迁移时，我发现了第一次迁移生成的迁移文档依然正常的，

创建表这些，但当我更改数据库模型，提前准备更新数据库系统时，

我发现了这类接口方式有一个棘手的问题，搞得我根据

flask db migrate每一次生成的迁移文档全是创建表，

但在运作flask db upgrade 一直出错，表早已存在。

瞎折腾了好久，总算找不到答案了，如有神助影响了接口方式，果真

这是人之常情。尽管它仍是警示，但是它的不正确好。

听上去有点儿杂，但也是苦泪啊。

说到这里，还有一个最基本的目录架接下来就是我们继续提升我们自己的功能编码，

功能目录，希望能在要求转变的时候能够更加高效。