为什么很多人都喜欢 Django 的 ORM 而不是 SQLAlchemy，是因为简单吗？

回复内容：

Django 的 Model 驱动对数据库层面上的实现细节关注的非常少，开发者定义模型的过程非常接近声明式而非过程式，对于新项目来说，可能是这个原因让 Django Model 比 SQLAlchemy 讨人喜欢。

传统的 SQLAlchemy 的使用方法是不入侵模型，在单独的地方定义表结构、映射规则，然后用 SQLAlchemy 驱动注入到模型类里去，这种方法可以完全避免模型与数据库的耦合，但是定义繁琐，要求开发者完全明白 engine、metadata、table、column、mapper 等概念，如果没有读过《企业应用架构模式》一类书籍会被弄得很乱。

现在 SQLAlchemy 提供了 declarative 的方式，和 Django Model 很像，但是和声明式模型还是有一定的距离，好在对于灵活性几乎没损失。但是我对比了一下 Django Model 和 SQLAlchemy declarative，发现 Django Model 还是更简洁一些。例如对于类关联，Django 只要直接声明外键，就自动产生关联对象，而 SQLAlcyhemy 要定义外键、relationship 对象，如果有多个外键还要自己指定 join 规则…… 总之灵活性是好东西，但是不是什么情况下都讨人喜欢的。

我本来想说这个是 ActiveRecord style 和 Data Mapper style 区别导致的，但是细想了一下，Django Model 并不是简单的 ActiveRecord，其对于复杂关联甚至继承的映射都有很好的适应性，应该和 SQLAlchemy 的 declarative 是同类型的，是对 Data Mapper 的 Active Record style 包装。 sqlalchemy使用上有两个层次，1是使用sql expression, 说白可以让你用python写sql， 2是它的orm, orm是使用session的，自行管理session生存期，自行在多个过程中传递session，自行管理事务。写法上是通常的transaction script（java常说的贫血的domain model)模式。实际编码通常1和2混合编程。
django通过中间件部分隐藏了连接/事务管理的概念，写法上也比较简单，接近java常说的充血的domain model. 内容上也没有sqlalchemy 的sql expression层次。 易用性就体现出来了。

不过用过的orm中，能达到sqlalchemy这样高度的orm, 还没有在其他语言中看到。 ruby有sequal, java的jooq都有部分sqlalchemy思想的影子 因为在Django世界中它的ORM就是事实标准。Django最重要的特色是什么？从ORM快速生成后台管理界面！另外还有ModelForm、数据迁移(migration)等等从Django ORM延伸出去的概念……如果你选用了SQLAlchemy，那么这一切都没有了，你必须自行搭建，或者选用第三方库。话说，没有了内置ORM、没有了内置后台管理界面、没有了内置ModelForm、没有了数据迁移的Django，还是Django吗？不如直接用其它更轻量或更松散的框架好了！

另外，在Django之外单独使用Django ORM是不靠谱的。如果是其它环境，使用SQLAlchemy就好了。 我从2006年开始，翻译过SQLAlchemy、Django、SQLObject的文档。你自己去看看英文文档就知道了，SQLAlchemy那是给人看的么？一个ORM而已，搞了1000页的文档，而且字特别密集，废话一萝筐。我都怀疑写文档的人是不是在用英文的某种文言文在写，简单的话，却几乎各种同义生词，奇怪语法。

英文文档里一个对立面可以参考Flask的文档，那叫一个简单易懂。

2006-2007年，我依次完成了SQLObject和SQLAlchemy的文档后(部分翻译)。发现SQLObject在逐渐没落(现在很多人都没听说过了)。而SQLAlchemy又是如此奇葩的存在。就只好搞定了DBUtils，然后就不再用任何ORM了。

以我的观点，ORM是在SQL之上的封装，而这种封装引入了太厚的封装，使得程序员对底层的控制力明显减弱，又加入了太多新的设计。所以我是不赞同使用ORM的，还是干干净净的SQL好用的多。 用ORM图的就是简单方便，Django的ORM正巧满足了这个需求，复杂的直接用原生SQL就可以了 Django的orm什么时候独立出来啊....