ORM 试图解决哪些数据库没有解决的问题？

Question

我在一家大型企业中与 15 名开发人员一起工作。我们处理许多在 OLTP 数据库上有数百万条记录的表。数据仓库数据库要大得多。

我们正在着手开发一个需要开发的新系统，该系统将针对一个非常相似大小的数据库。我们每个人都非常精通 SQL、存储过程等。检查执行计划、定义正确的索引等。我们都非常熟悉 .NET C# 和 ASP.NET。

但是，我们每个人都在独立研究 ORM，但没有人能够理解它们解决的真正问题。相反，我们看到的是人们遇到的性能问题以及需要进行的所有调整以弥补不足。

另一个方面似乎是人们使用 ORM 是为了不必在处理数据库和 SQL 等时弄脏自己的手，但实际上你似乎无法逃避它太久，尤其是当说到性能。

所以我的问题是，ORM 解决（或试图解决）的问题是什么。

我应该注意到，我们的 OLTP 数据库中有大约 900 个表和超过 2000 个存储过程，我们的数据层是从我们的存储过程自动生成的，我们目前使用 ADO.NET 核心。

Answer 1

ORM 尝试解决 object-relational impedance mismatch。

也就是说，由于关系数据库在本质上是......关系，因此用于它们的数据建模与您在 OOP 中使用的建模类型非常不同。

这种差异称为“对象关系阻抗不匹配”。 ORM 试图让您使用 OOP，而不考虑数据库的建模方式。

Answer 2

ORM 适用于那些认为在对象中一切都会更好地工作的面向对象的人。他们在 OO 技能比 SQL 和关系数据库更强大、更丰富的项目中拥有最佳机会。

如果您使用面向对象的语言编写代码，您将不得不一次又一次地处理对象。无论您是否使用 ORM，您都必须将数据从表中取出并放入中间层的对象中，以便您可以使用它们。 ORM 可以帮助您解决单调乏味的映射问题。但这不是 100% 必要的。这是一个和其他任何选择一样的选择。

不要犯使用对象编写客户端/服务器应用程序的错误。如果您的对象只不过是从数据库到客户端的数据载体，我会说您做错了什么。将行为封装在有意义的对象中是有价值的。

Answer 3

我认为，与所有这些事情一样，是否应该使用 ORM 的问题的答案是“视情况而定”。在很多情况下，人们可能会在后台使用相对较小的数据库编写相对简单的应用程序。

在这些情况下，ORM 是有意义的，因为它可以轻松维护（添加一列是一个地方的更改，让它在您的应用程序中产生涟漪）和快速周转。

但是，如果您正在处理非常大的数据库和复杂的数据操作，那么 ORM 可能不适合您。也就是说，具有数百万行的表对于 ORM 来说仍然不是问题，这完全取决于您如何返回和使用数据 - 一个结构良好的数据库应该允许合理的性能。

在您的情况下，您看不到好处，因为它可能不适合您的应用程序 - 它适用于其他一些应用程序。

---

顺便说一句-您在问题中描述的内容-用于生成业务层中使用的类的存储过程。这本质上就是一个好的 ORM 映射器 - 摆脱编写样板数据访问代码并处理业务逻辑。

Answer 4

非常好的问题。这取决于您要构建的内容。

如果你有复杂的对象结构（有很多关系的对象和封装的对象），并且你在提交事务之前在内存中操作这些对象，那么像 Hibernate 一样使用 ORM 会容易得多，因为你不需要担心 SQL 、缓存、即时对象加载等。作为奖励功能，您将获得相当好的数据库独立性。

如果您的应用程序中有非常简单的对象，没有太多功能/方法，您当然可以使用普通的 SQL/DB 连接。但是我还是建议您使用 ORM，因为您将独立于数据库，更便携，并且您将准备好扩展，当您的系统需要即时对象加载、长事务（带缓存）等时。

我在生活中使用过许多持久性框架，我会推荐 Hibernate。

Answer 5

简而言之，它确实试图让数据库在程序员看来是对象，因此程序员可以提高工作效率。唯一的好处（除了帮助开发者懒惰之外）是映射到类的列是强类型的 - 不再尝试将字符串获取到整数变量中！

多年来，ORM 库来来去去，它们似乎（恕我直言）都只是另一个程序员玩具。归根结底，它是另一种抽象，可以在您开始或编写小型应用程序时帮助您。我在这里的意见是，一旦你学会了一种访问数据库的好方法，你还不如继续使用这种方法，而不是学习完成相同任务的多种方法——我总是觉得作为专家更有效率，但这可能只是我。

创建和维护映射、生成类等所需的工具是另一个麻烦。在这方面，内置框架（例如 ruby​​ on rails 的 ActiveRecord 方法）要好得多。

性能可能是一个问题，在后端生成的 sql 也是如此 - 与您可能编写的小型 SQL 语句相比，使用 ORM 时，您几乎总是会获取比您需要的更多的数据。

虽然强类型很好，但我会为此称赞 ORM。