视频

了解更多
大多数软件开发者都熟悉对象关系映射(ORM),这是一种在面向对象编程语言和数据库之间创建抽象层的编码技术。尽管 ORM 具有价值,但在所有情况下并非都适用——尤其是在程序员对其使用做出错误假设时。我们将揭穿一些此类误解,以便您正确使用 ORM。
请勿误解:我们很欣赏 ORM。Redis 热忱支持这项技术,并提供对多种编程语言的支持。但重要的是要正确入门。
在其最纯粹的形式中,ORM 充当连接系统的翻译器。它们提供了很大的灵活性,允许程序员通过他们偏好的编程语言简化通信,而不是直接依赖结构化查询语言 (SQL) 或其他数据库特定语言。由于系统通常依赖于不同的编程语言并以不同的方式存储数据,因此很容易引入复杂性。没有 ORM,许多面向对象的应用程序将难以与数据库通信。
尽管如此,程序员可能对 ORM 的作用产生误导,这导致混淆,有时还会带来挫败感。
这三个误解可能会阻止您正确使用 ORM 并从中获得最大益处。那将是一种遗憾。
你肯定熟悉 SQL,这是用于在关系数据库中存储、操作和检索数据的标准化语言。你使用特定的查询与数据库交互:INSERT、SELECT、UPDATE、DELETE、DROP TABLE 等等。
ORM 帮助程序员以他们偏好的语言(例如 Python)与数据库交互,而不是手动从头编写 SQL 查询。这是一个显著的优点。使用 ORM,数据以结构化的方式建模,这有助于程序员与数据库的布局和内容进行交互。
你不需要使用 SQL,因为 ORM 为你做了很多工作。这节省了时间和精力,特别是对于不了解 SQL 或对其技能缺乏信心的人来说。根据 2020 年 StackOverflow 的调查,全球只有 56.9% 的开发者使用 SQL。 但是,快捷方式不等同于为无知辩护。一些开发者认为“我不需要深入了解 SQL”等同于“学习数据库概念 是不必要的,因为 ORM 从头到尾都包办了。”
这不是真的。
ORM 对于简单的 SQL 查询非常有用。但是,当你进行任何复杂操作时,你需要了解 SQL 的能力,以便充分发挥其功能。这并不奇怪。你对其他开发工具也是如此。工具是为了支持我们的工作,而不是取代我们的理解。
然而,开发者有时会将“我有一个帮助我的工具”泛化为“如果你有一个工具,你就不需要了解任何关于数据库设计的东西。” 高级抽象并不总是能写出最优的代码。它们容易出错,你需要理解 SQL 才能识别何时出现问题。如果你不理解 SQL,调试、性能调优或整理复杂数据会变得更加繁琐和令人沮丧。
了解 SQL 可以让你对应用程序有更多的控制权,并允许你调整 SQL 查询以优化性能。使用 ORM 来帮助你更快地工作——而不是阻止你思考。
一些反对 ORM 的人持这样的态度:总是自己编写 SQL 查询更好。他们认为 ORM 提供的唯一功能就是编写 SQL 代码。
但软件的功能超出了编写查询。ORM 参与到面向对象模型中,以及数据如何在数据库和该模型之间移动;这与实际编写 SQL 查询是正交的。
ORM 还促进代码的可维护性和重用,因为它们使开发者能够以对象而不是原子化的数据块来思考。
SQL 注入的结果可能是灾难性的,导致未经授权的数据库访问。 幸运的是,ORM 在保护应用程序免受 SQL 注入攻击方面更有效。它们可以将对象和操作映射到数据库相关的代码中,因此你无需手动编写特定的安全代码。
然而,“它有帮助”不等同于“...所以它是万无一失的。” ORM 包并不能使你的数据库应用程序免受网络安全攻击。与任何软件一样,ORM 也可能存在错误(甚至 Hello World 也存在漏洞),使数据驱动的应用程序暴露在另一个攻击领域。
ORM 防御 SQL 注入攻击的主要方式是使用参数化查询。然而,并非所有 ORM 都以这种方式工作。在你认为某个 ORM 安全之前,至少应该验证它是如何将你的操作转换为 SQL 的。
为了获得更好的保护,请实施所有手动编写代码时会采用的数据库安全技术。无论应用程序如何创建,都要确保你的软件质量保证流程包含完整的安全测试套件(不仅仅针对 SQL 注入攻击)。ORM 可能减少安全漏洞的可能性,但安全起见总是最好的。
在 Redis,我们热衷于任何能让应用程序开发更快、更准确、更有效的工具——让程序员可以思考创新方法来帮助数据驱动的应用程序更好地服务其用户。所以当然,我们完全支持 ORM。它们促进了代码重用,并在数据访问层提供了更清晰的分离。
Redis OM 客户端库的介绍解释了对象映射器如何帮助你充分利用 Redis 的模块。Redis OM 的目标是提供一个高级抽象工具箱,让你在使用最熟悉的编程环境时轻松处理 Redis 数据。它包含四个用于 Redis 的高级客户端库,我们邀请你探索:
正在寻找其他相关概念的定义?请查看我们的术语表部分。