用惯了 django 改用 flask 有感

理论上可以自己自由搭配需要的 package，但是如果要全部达到 django 自带模块的功能或者标准，估计需要海量时间，就像要把 linux 配置的长得像 mac，只要花时间还是能做到的
由于需要定制的东西比较多，所以逼着你了解他底层的机制，就像学 linux 难免要了解一些硬件或者 os 的底层机制
文档过于简单（这个缺点 linux 好像没有）

Linux

django

flask

底层

50 条回复 • 2019-07-27 19:38:59 +08:00

est

2019-07-15 22:10:53 +08:00

flask 吹过头了。

echo1937

2019-07-15 22:28:35 +08:00

我把 Django 看作是 Python Web 开发的一种最佳实践的集合。

Abbeyok

2019-07-15 22:33:25 +08:00 via Android

各有所爱吧，反正我用 flask 用着挺好

Takamine

2019-07-15 23:29:04 +08:00 via Android

如果是为了把 Linux 配置成 Mac 却还选用 Linux 的话，不是自己想要重新造轮子就是闲出屁了。:doge:

whoami9894

2019-07-15 23:34:57 +08:00 via Android

没怎么用过 Django，不过感觉 flask 的周边 package 大多都是开箱即用，没太大硬伤

lynskylate

2019-07-15 23:44:34 +08:00 via Android

django+drf crud 开发效率实在太高了，flask 自定义起来更方便，代码写的实在太巧妙了。

janus77

2019-07-16 01:34:05 +08:00 via iPhone

我怎么两年前听说的是这样的说法：flask 开箱即用简单需求，django 适合复杂大型系统
？？？

kxiaong

2019-07-16 01:50:21 +08:00

刚把公司之前的一个 flask 老项目用 django 重写。

用 flask，ORM 就是绕不开的一个坑。sqlalchemy 虽然强大，却隐藏了不少坑。除非经验丰富，否则用 sqlalchemy 就是找虐。

最喜欢的还是 django 的 ORM，开箱即用，简单明了。框架约束多，可以保证新手不留烂坑。

高手可能有自己的想法，但是 python 本身就足够灵活，在框架选择上，还是尽可能保守一些更好。

rainmakeroly

2019-07-16 02:16:05 +08:00 via Android

记得好像 Flask 的文档应该算是比较详细的了。

troywinter

2019-07-16 02:16:59 +08:00

曾经用 flask 写过两年的 production 级服务，自己组织了代码的分层架构，用装饰器实现相应的依赖注入，实现了 clean architecture 的六边形架构，对 sqlalchemy 也做了各种封装，感觉对于定制需求很多的人来说很合适。

自己定制可以实现更好的正交性，和 DDD 相结合，各个模块之间可以更合理的组织，曾经公司新来的同事再看到我写的项目之后都会很惊喜，认为我组织的项目结构很好的反应了业务的关系，让他们很好接手（ PS 这几个同事是 Django 背景）。

了解底层机制无可厚非，这也是 flask 在设计时想要做的，我认为不懂 wsgi 这些 web 框架原理的是不合格的开发者，这些都是一年经验就能掌握的，相反的，如果框架做的大而臃肿，用户使用时不能理解设计的理念，api 设计没有正交关系，我觉得这并不好。另外，文档过于简单的话，我没体会到，本来就很小的框架，看文档我觉得所有 api 都讲解的很详细，除非你指那些扩展。

说到文档，记得有个笑话，The Django Documentation has more words than the Bible, and I know a whole lot of them by heart. 对不起，我大学四年 Bible 都没学完，Django 的文档实在看不完。

marco25

2019-07-16 08:31:21 +08:00

@troywinter @rainmakeroly flask 文档确实还 ok，但是和 django 比对新手的友好程度上还差不少。我碰 django 的时候连 http 基本的概念还不大清楚，也能完整地一步步跑起来。django 的文档不像文档，像是小说:-)所以你说的 more than bible 也是不夸张的。。。

newdongyuwei

2019-07-16 08:35:28 +08:00

做 web 开发追求生产效率就得上 full stack 的开发框架，用 flask 是自虐。sqlalchemy 也是渣渣。

c00WKmdje2wZLrSI

2019-07-16 08:47:51 +08:00

很小的项目的时候用 flask 倒是很爽，一个文件就解决了

coolair

2019-07-16 09:07:07 +08:00

@troywinter #10 很想学习学习你的依赖注入、六边形架构和对 sqlalchemy 的封装，有空写篇长博客介绍介绍吗？感谢。

NoirStrike

2019-07-16 09:07:34 +08:00

django admin 太香了...

tonnycao

2019-07-16 09:13:17 +08:00

@troywinter 可以分享一下架构吗？

qq976739120

2019-07-16 09:23:28 +08:00

系统稍微复杂点,django 的 orm 就不是优势了,很多时候都是各个库里做个简单查询,数据都是各种地方拼凑起来的,web 框架和 orm 做的并不多,那些 if else 用什么语言用什么框架写都一样,但是如果是个刚起步的小项目,django 的确帮你做好了很多优秀的封装,撸就完事了,而且 django 的文档真的业界标杆.

Outliver0

2019-07-16 09:27:28 +08:00

奔向 asgi

cnanyi

2019-07-16 09:29:00 +08:00

django admin 撸后台神器，基本的 CRUD 包括 UI 都有了，增加一些自定义功能也都有对应的方法，太香了

rogwan

2019-07-16 09:31:06 +08:00 via Android

@kxiaong SQLalchemy 会有哪些坑？

@newdongyuwei SQLalchemy 什么地方比较渣？

37Y37

2019-07-16 09:31:52 +08:00

站 Django，不得不说实在太好用了

dzm

2019-07-16 09:35:57 +08:00

做 web django ORM 和 admin 的配合几乎为所欲为,现成的东西太多了.

mengzhuo

2019-07-16 09:41:46 +08:00 via iPhone

bottle 表示这 flask 要叫爷爷

crackhopper

2019-07-16 09:43:24 +08:00

flask 比较玩具，底层并不代表优势（你咋不用系统 socket 编程？）。django 用的多了，仍然需要很深入了解，因为有对应组件的源码，所以反而更方便深入。其他方面就不多说了，简单来说，flask 适合做 demo，做产品级别应用并不省力气反而麻烦比较多。

rogwan

2019-07-16 09:49:10 +08:00 via Android

@mengzhuo 早先是 flask 的作者 A.R.提议 bottle 改，瓶子没鸟他，A.R.就自己搞了个 flask （烧瓶），烧瓶看上去是烧掉瓶子的意思

matrix1010

2019-07-16 10:02:42 +08:00

复杂的项目还是要上 Django, 有问题看源码就行。而且就算是 Django 也需要很多 package 支持，我最近就写了一个用来 cache/memoize 的: https://github.com/Yiling-J/django-cacheme

mywaiting

2019-07-16 10:05:42 +08:00

Ruby 圈有句话叫 You will end up reinventing Rails, in a horrible way. via /t/297504

用到 Python 上就是 You will end up reinventing Django, in a horrible way.

lycbug666

2019-07-16 10:16:57 +08:00

@troywinter #10 是否能分享一下?

yanzixuan

2019-07-16 10:43:18 +08:00

其实初学者真不建议 flask，因为 django 的规范能让你养成很多好习惯。

janxin

2019-07-16 10:49:02 +08:00

新人上手推荐 Django 吧，规范化对新人的规范作用很大，否则写出来的项目很容易就惨不忍睹了。而且从资料丰富度上 Django 还是最完善的。

对于老手，flask 充分给予了你定制的可能性，身负屠龙技，万物可屠龙

dongxiaozhuo

2019-07-16 12:00:57 +08:00

@rogwan 猜测其他楼层说的 sqlalchemy 的坑可能包含但不限于 orm session、复杂 sql 的问题。

sqlalchemy 如果使用 orm 操作数据库时默认使用事务，并且会引入一个 sqlalchemy session 的概念，与 db 的 connection 有区别，sqlalchemy 的文档推荐在 web 框架中做到 request context 级别的管理。如果直接 flask + sqlalchemy，如果没有手动回收 session，会出现过多事务未提交的错误，重启应用能释放这些未提交的事务。flask-sqlalchemy 使用 flask 的 app context 机制做了 orm session 在 request context 级别的回收。

复杂 sql 的问题，不管是 orm 层还是 core 层（ sql ）都会显的特别难受。复杂场景下，只能通过代码规范来限制 sql 拼接在代码不同层级的扩散。

---

关于本帖重点讨论的 Django 和 Flask 都只是轻量级的使用过，这两点好处自然不必说了。说说最近处理的问题。

最近一次处理 Django 的问题是，Django 的配置问题，Django 使用 import module 的方式获取变量，遇到了架构中使用了配置中心下发配置的情况，就显得非常尴尬。

最近一次处理 Flask 的问题是，从 Flask 迁移到其他框架时，业务代码中使用到的全局变量 g，结合业务的使用起来，迁移到其他框架 or 语言时，就要再造一次全局安全的 g 或者转换业务的实现形式。

这两个问题都是框架特有的使用方式与业务场景的绑定导致的问题，
---
个人理解：适当的使用框架但是不要被框架绑定了。

tiedan

2019-07-16 12:08:16 +08:00

用 django 如果业务流量大的话，记得换掉 django 自带的数据库连接池换成 sqlalchemy 的

Hopetree

2019-07-16 12:18:47 +08:00

小服务（个位数接口）使用 flask 比较好，在公司经常用 flask 搭建一些小服务，就提供单个功能，一个文件就搞定了，这并不是说 flask 不适合大型项目，只是说 flask 相较于 django 来说更便捷。如果涉及后台和用户管理的，flask 想想就麻烦，而 django 已经帮你弄好了

lolizeppelin

2019-07-16 13:07:17 +08:00

django/flask 都没用过

照楼上说法,比 flask 更轻量的 pecan 之类别活了

rogwan

2019-07-16 13:22:23 +08:00

> 如果直接 flask + sqlalchemy，如果没有手动回收 session，会出现过多事务未提交的错误，重启应用能释放这些未提交的事务。

@dongxiaozhuo 这里是不是理解反了？（源码中自动在每一次请求上下文之后，会自动 remove 啊）

----------------------------

@app.teardown_appcontext
def shutdown_session(response_or_exc):
if app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN']:
if response_or_exc is None:
self.session.commit()

self.session.remove()
return response_or_exc

dongxiaozhuo

2019-07-16 14:14:50 +08:00

@rogwan 你发的这段代码时 flask-sqlalchemy 这个库里面做的事情，如果直接使用 flask 配合 sqlalchemy 就不会处理这一部分。

rogwan

2019-07-16 14:27:06 +08:00 via Android

@dongxiaozhuo 我没注意看你分别写的是 flask + sqlalchemy 和 flask-sqlalchemy -:)

zhuangzhuang1988

2019-07-16 14:31:10 +08:00

django 好。

troywinter

2019-07-16 14:36:36 +08:00

@coolair
@lycbug666

之前一直没有整理这块的架构，等我写好了分享一下，哈哈

其实总体思想就是 web 框架层，业务层和持久化层分开，不互相依赖使得它们可以轻易被替换，因为开发过程中我用了 TDD，所以每个模块必须是 decoupled，不然没法测试，然后其他的模块会有一些想 policy engine 负责对实际运营需求有不同的 policy，还有一些对接第三方服务，使得它们都可以轻易测试。

对于上面提到的 sqlalchemy 的问题，我觉得按照文档来就行了，文档提供了比较好的方向性的指点，比如 session 是 request 级的，不会被共享，我的方法是用 decorator 创建 session，诸如到 controller 中，其它的依赖注入比较类似，动态语言里真的好舒服。

charlie21

2019-07-16 15:48:57 +08:00

反正都是 API caller，用啥都一样。自己写一个 flask 用阿

impl

2019-07-16 22:13:52 +08:00

不是还有个叫 tornado 的，没人用了现在？

encro

2019-07-16 22:36:14 +08:00

flask,laravel,gin,vue 等等，核心思想是粘合剂，所以灵活、起步容易、约束少，适合人少的小型项目，或者有则良好开发水平和自我约束能力团队的中大型项目。
django,yii,ror,springboot,angular 等等，核心思想是最佳实践+约定，所以起步难，开发效率高，约束多，适合中大型团队，因为写代码都是一个样子的。
从维护性，学习编程思想，个人提高上来说，建议团队上后者，个人项目上前者后者都行。