作为一个曾经在 和 Flask 两边都做过开发工作的人员, 在今天的内容里, 我会专门从以下这四个具体的方面来进行详细的阐述和操作分析, 这四个方面具体是指: 开发体验、性能调优、业务复杂度以及团队协作, 我将这两个 ORM, 也就是对象关系映射工具, 进行拆解之后来进行非常充分的讨论。
我们不仅会讲述相关的理论知识, 还会提供一些代码方面的具体示例, 以便你能够看得更加清楚明白, 从而让你在选择的时候更加安心放心。
在第一部分的内容里, 我们将首先对两位主角进行一番认识, 那么具体而言, 究竟什么是 ORM 呢?
如果你用过 框架，那它自带的 ORM 你肯定用过。你只管写类，数据库表它替你建；你写查询，它帮你拼 SQL，简直像有个贴心的"小秘书"。
class Book(models.Model):title = models.CharField(max_length=100)
price = models.DecimalField(max_digits=6, decimal_places=2)
这一写下去, 后面的那些数据迁移、增加、删除、查询以及对记录的修改等操作, 那个ORM工具都一站式全都给包了。
什么是 ？
而在这一点上呢, 它更像是个老派的硬核工程师。这个框架能够给你提供全自动的对象关系映射服务。它也能够让你通过手写 SQL 的方式来自行发挥。而且这种架构和 Flask。
class Book(Base):__tablename__ = 'books'
id = Column(Integer, primary_key=True)
title = Column(String(100))
price = Column(DECIMAL(6, 2))
它并不具备那种所谓的一站式全部包办的功能, 但是你如果需要去进行额外的功能扩充的话, 你是可以实现完全按照你的想法去操作的。
第二部分是关于核心对比的内容, 主要分析哪个工具更适合你进行选择。在第一点入门难度方面进行对比时, 结论是ORM这一种方式更加适合那些刚刚起步的初学者去使用。
如果你是新手, 想尽快上线一个后台管理系统或者博客, 那么 ORM 里的约定大于配置这个概念会让你觉得几乎用不到做什么额外的设定就能直接开始使用了。
反观, 虽然自由度很高, 但也意味着你要自己去管理、、映射类等等。
对于新手来说, 推荐他们去使用那种名叫 ORM 的技术, 因为这样一来, 事情就会处理得相当顺手、顺畅。
- 在查询复杂度的方面, 它能够变得更加灵活, 同时也显得更强大。
我们来看一个稍微复杂一点的例子，假设你说要去找那些售价是大于 50 的图书, 并且呢, 还要按照这个价格从高到低的顺序来排个序。
ORM：
Book.objects.filter(price__gt=50).order_by('-price')：
session.query(Book).filter(Book.price > 50).order_by(Book.price.desc()).all()在这一步里, 他们两个算是打个平手。但是, 如果你需要进行联表查询多个模型的字段、进行子查询、进行聚合分析或者使用原生 SQL 嵌套的话, 的"暴力美学"就会展现出来了。
比如联表查询：
session.query(Book, Author).join(Author).filter(Author.name == "Echo")虽然 ORM 也能够用来做这件事, 但是相关的 API 接口在编写的时候会显得更为错综复杂, 并且从底层来看, 操作者完全无法直接干预或插手关于 SQL 语句生成的具体过程。
- 在性能调优方面, 这意味着实现了更加可控的状态。
你是不是想要加入那个连接池的内容? 是不是也想要对事务的粒度来进行控制? 是否还有那个进行sql精调的想法? 这些情况都是可以的。
它把连接引擎、元数据、管理都拆成独立组件, 让你在性能调优时可以精准控制, 比如使用:
engine = create_engine("postgresql://...", pool_size=10, max_overflow=20)ORM 这个技术的改进余地实际上是比较小的, 特别是在那些并发访问量很大并且查询条件很复杂的时候, 它的运行速度往往就会成为一个明显的限制因素。
- 生态集成方面, ORM 这一事物是拥有像"自动驾驶"这样的一种体验的。
ORM 这种技术的厉害地方, 不光是在于它自己有多强, 更重要的是它可以和 Admin、Form、Rest这些东西合在一起形成一套完整的体系。如果要做后台系统的话, 你基本上是用不着去写任何 SQL语句的。关于那些增删改查的基本功能, 大概花个十分钟就能搞定全部的事情。
正是因为这个原因, 所以说, 在很多企业内部管理系统、内容管理系统以及B2B工具当中, 它被大家普遍认为是首选的那个东西。
- 关于可维护性以及团队协作这两个方面, 我们需要把不同的情况进行分门别类的讨论, 然后根据这些具体情况给出相应的项目或者技术选型的建议和方案。
场景
推荐 ORM
新人建站、企业后台、Admin 系统
ORM
框架是Flask。
进行数据的导入和导出操作, 以及使用ETL工具。
中小团队、快速迭代
ORM
在高并发的环境下, 会出现性能方面的瓶颈问题, 同时涉及多个数据库的使用情况。
需要去采用异步进行查询的方法, 也就是那个async。
1.4+
最新的技术趋势, 这一点, 大家现在看得很清楚, 它正在进行一个全面的升级动作。
它的版本跨度, 是从 1.4 直到 2.0。它目前已经支持 async/await, 支持 2.0 风格。它也支持 类型提示。写起来的感觉, 越来越像 ORM。它的内容和功能方面, 并没有缺失。
示例 async 查询：
async with async_session() as session:result = await session.execute(select(Book).where(Book.price > 50))
books = result.scalars().all()
在未来, 你可能就不会再被迫去做出非此即彼的那个选择了, 你完全可以把不同的模块混合起来使用, 具体到操作的时候, 如果是在管理后台这个地方, 你可以去选择使用 ORM 这种技术, 而如果是数据服务这个具体的模块, 你又可以去做另外的安排, 到底谁能够规定你就不能同时兼顾这两方面的需求呢。
关于最后的那些个人感受方面的想法, ORM 这种东西应当被看待为是一种可选项, 而不是一种需要去信仰的东西。
不管你选谁，记住一点：
ORM这个玩意儿, 它可不是你的主子, 顶多算个工具罢了。千万可别被那些框架给绑住手脚, 要把自己这个项目到底是个啥样子的、到底需要个啥, 这些东西给弄明白, 这可比啥都重要。
像我这个人, 对于那两个所谓的对象关系映射框架, 我是使用次数已经非常多, 并且也遇到过好多好多困难。我心里面是非常清楚的:
一句话总结
ORM 是高铁，准时快速自动驾驶； 是越野车，自由但你得会开。