0基础跟我学python---进阶篇（3）python中的ORM框架（1）

📢📢📢📣📣📣
哈喽！大家好，我是「奇点」，江湖人称 singularity。刚工作几年，想和大家一同进步🤝🤝
一位上进心十足的【Java ToB端大厂领域博主】！😜😜😜
喜欢java和python，平时比较懒，能用程序解决的坚决不手动解决😜😜😜

✨ 如果有对【java】感兴趣的【小可爱】，欢迎关注我

❤️❤️❤️感谢各位大可爱小可爱！❤️❤️❤️
————————————————

如果觉得本文对你有帮助，欢迎点赞，欢迎关注我，如果有补充欢迎评论交流，我将努力创作更多更好的文章。

上一章我们连接了python中比较基础的方式实现对数据库的操作，虽然完成了对数据的增、删、改、查的操作，但是很不友好，操作起来很复杂，对很难用！！！很难用！！！很难用！！！

所以对于程序🐒来说，难用的东西就把它革掉好了。所以ORM就应运而生了。

学习过数据库和其他语言的小伙伴们肯定听说过ORM。ORM（Object Ralational Mapping，对象关系映射）用来把对象模型表示的对象映射到基于S Q L 的关系模型数据库结构中去。这样，我们在具体的操作实体对象的时候，就不需要再去和复杂的 SQ L 语句打交道，只需简单的操作实体对象的属性和方法。O R M 技术是在对象和关系之间提供了一条桥梁，前台的对象型数据和数据库中的关系型的数据通过这个桥梁来相互转化  。大大方便了对数据库的操作。

今天我们就来唠唠python中的ORM框架。

目录

📚1.常见的ORM框架

（1）SQLObject

（2）Storm

（3）Django's ORM 

（4）peewee

（5）SQLAlchemy

📖 2.为什么需要ORM

---

📚1.常见的ORM框架

python中有很多ORM框架，今天我们就来扒一扒这些框架把，看看和java中的框架有什么不同之处。

（1）SQLObject

SQLObject是一种流行的对象关系管理器，用于为数据库提供对象接口，其中表为类，行为实例，列为属性。

SQLObject包含一个基于Python对象的查询语言，使SQL更抽象，并为应用程序提供了大量的数据库独立性。

优点：

采用了易懂的ActiveRecord 模式 

一个相对较小的代码库 

缺点：

方法和类的命名遵循了Java 的小驼峰风格 

不支持数据库session隔离工作单元 

（2）Storm

Storm 是一个介于 单个或多个数据库与Python之间 映射对象的 Python ORM 。为了支持动态存储和取回对象信息，它允许开发者构建跨数据表的复杂查询。Stom中 table class 不需要是框架特定基类 的子类 。每个table class是 的sqlobject.SQLObject 的子类。

优点：

清爽轻量的API，短学习曲线和长期可维护性
不需要特殊的类构造函数，也没有必要的基类
缺点：

迫使程序员手工写表格创建的DDL语句，而不是从模型类自动派生
Storm的贡献者必须把他们的贡献的版权给Canonical公司

（3）Django's ORM 

因为Django的ORM 是紧嵌到web框架的，所以就算可以也不推荐，在一个独立的非Django的Python项目中使用它的ORM。

Django，一个最流行的Python web框架， 有它独有的 ORM。 相比 SQLAlchemy， Django 的 ORM 更吻合于直接操作SQL对象，操作暴露了简单直接映射数据表和Python类的SQL对象 。

优点：

易用，学习曲线短 

和Django紧密集合，用Django时使用约定俗成的方法去操作数据库 

缺点：

不好处理复杂的查询，强制开发者回到原生SQL 

紧密和Django集成，使得在Django环境外很难使用 

（4）peewee

优点：

Django式的API，使其易用 

轻量实现，很容易和任意web框架集成 

缺点：

不支持自动化 schema 迁移 

多对多查询写起来不直观 

（5）SQLAlchemy

SQLAlchemy 采用了数据映射模式，其工作单元 主要使得 有必要限制所有的数据库操作代码到一个特定的数据库session，在该session中控制每个对象的生命周期 。

优点：

企业级 API，使得代码有健壮性和适应性 

灵活的设计，使得能轻松写复杂查询 

缺点：

工作单元概念不常见 

重量级 API，导致长学习曲线 

总结：

	优点	缺点
SQLObject	采用了易懂的ActiveRecord 模式  轻量	方法和类的命名遵循了Java 的小驼峰风格  不支持数据库session隔离工作单元
storm	清爽轻量的API，短学习曲线和长期可维护性 不需要特殊的类构造函数，也没有必要的基类	手工写表格创建的DDL语句，而不是从模型类自动派生 贡献者必须把他们的贡献的版权给Canonical公司
Django's ORM	易用，学习曲线短  Django紧密集合，用Django时使用约定俗成的方法去操作数据库	不好处理复杂的查询，强制开发者回到原生SQL 紧密和Django集成，使得在Django环境外很难使用
peewee	Django式的API，使其易用  轻量实现，很容易和任意web框架集成	不支持自动化 schema 迁移  多对多查询写起来不直观
SQLAlchemy	企业级 API，使得代码有健壮性和适应性  灵活的设计，使得能轻松写复杂查询	工作单元概念不常见  重量级 API，导致长学习曲线

相比其他的ORM， SQLAlchemy 意味着，无论你何时写SQLAlchemy代码， 都专注于工作单元的前沿概念 。DB Session 的概念可能最初很难理解和正确使用，但是后来你会欣赏这额外的复杂性，这让意外的时序提交相关的数据库bug减少到0。在SQLAlchemy中处理多数据库是棘手的， 因为每个DB session 都限定了一个数据库连接。但是，这种类型的限制实际上是好事， 因为这样强制你绞尽脑汁去想在多个数据库之间的交互， 从而使得数据库交互代码很容易调试

📖 2.为什么需要ORM

当时分享完毕之后，也确实很多同事表示还是喜欢裸SQL，我后来也又在工作中看到了很多遗留代码的问题。我也正好趁浴室迷思 想了一下，为什么我需要ORM呢？

第一条来自一个定理：

一切由人直接来保证安全性的系统，就一定会出错

拼接SQL、把SQL做成模板、开始使用ORM、封装出DAO层，几乎是每个项目的共识吧？
过往的项目中，由我第一手写的，都会第一时间加入ORM，毕竟也只是两三个小文件，一百行以内的事情（后续由于封装的增多，可能会到达数百行）

这段时间在写旧系统的小规模重构（定理2：一个好程序猿应当友好地帮前人擦好屁股，而不是靠重新制造一个新屁股实现），拼接字符串并没有带来任何优点，反而引入了非常简单的注入漏洞，简单的设想这样一个列表API的场景：

1. 根据请求参数控制对应的：过滤条件、排序方法、翻页
2. 根据需要预取关联的表，JOIN并把对一对多的关系化为一个list

第一条，刚一上手，就发现满地的string format，翻页用了：

order_sql = "ORDER BY {} {}".format(order_by,direction)

毫无疑问的order_by=id%3Bselect+1%3B-- 就直接注入了

要解决这些在SQL拼接的问题，除了表单验证，毫无疑问需要做一个SQL字符转义，另外在能用SQL参数的地方，需要用参数（然后也得注意拼接时候参数的个数，是的，这里我们的接口有另一个BUG，参数数量没数对）

第二个功能点，想象一下在需要的地方额外加一句LEFT JOIN，然后对结果再做额外的解析

还有一些附属功能：单元测试如何建表？代码里遍地的硬编码表名如何解决？

自己不是不能实现，但自己来实现这些，就走上了发明ORM的老路，用一个成熟的、文档丰富的ORM，岂不美哉？

后续我会继续更新这些框架的详细使用方法，敬请期待！也欢迎给我小伙伴们相互关注共同学习，共同进步，早日实现自己的财物自由，不去给他人打工，做自己想做的事情，好嘞好嘞，今天我们就先学习到这里，后续会把这些框架的学习列表贴到下面，欢迎有兴趣的小伙伴前来观看

如果觉得本文对你有帮助，欢迎点赞，欢迎关注我，如果有补充欢迎评论交流，我将努力创作更多更好的文章。