为什么很多人都喜欢 Django 的 ORM 而不是 SQLAlchemy,是因为简单吗?
- WBOYOriginal
- 2016-06-06 16:24:082450browse
回复内容:
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什么时候独立出来啊....
Statement:The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn