用惯了 django 改用 flask 有感

[marco25]

django 就像 mac

• 完成度高，开箱即用
• 但是因为开箱即用，有时并不会去了解太底层的东西
• 自带或者第三方的 package 的质量都不错，admin 秒 flask-admin 好几条街
• 文档极其好

flask 就像 linux

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

[37Y37]

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

[dzm]

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

[mengzhuo]

bottle 表示这 flask 要叫爷爷

[crackhopper]

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

[rogwan]

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

[matrix1010]

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

[mywaiting]

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]

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

[yanzixuan]

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

[janxin]

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

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

[mathgl]

用了 5 年的 cyclone,最近改用 django

[dongxiaozhuo]

@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]

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

[Hopetree]

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

[lolizeppelin]

django/flask 都没用过

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

[rogwan]

> 如果直接 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]

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

[rogwan]

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

[zhuangzhuang1988]

django 好。

[troywinter]

@coolair
@lycbug666

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

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

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