ORM是面向对象编程特有的问题吗?

嗯,是和否 .

你所指的是 Object-Relational impedance mismatch ,那就是 面向对象模型和实体关系模型之间的数据传输问题 . 这一困难是由于两种模型中构造和存储信息的方式本质不同,其中 OO是分层的,而ER是表格的 .

Object-Relational Mapping 是一种试图解决对象关系阻抗失配问题的技术。

“对象关系阻抗不匹配”一词是特定于 Object-Oriented 和 Entity-Relationship 模型。但是这个词 阻抗 指抵抗或困难,因此 阻抗失配 “可能用于表示两个不兼容的数据模型/类型系统之间的映射的一般问题。

至少,从轶事上讲,这种“阻抗不匹配”似乎是人们希望将关系推到对象习惯用法中的情况所特有的。

在C中,大多数数据库API倾向于将结果集公开为多维数组,而不是结构。因此,只需以与数据库中表中数据相同的格式访问数据——现在它作为数据的本地副本而不是“在数据库中”存在是不合理的。

大多数功能RDBMS库将数据库行公开为记录类型,这些记录与数据库行在相当深的层次上几乎完全对应。在这种情况下没有“阻抗失配”。

这个 Wikipedia article 在这个主题上,似乎可以推测为什么对象范式特别容易受到这种不匹配的一些原因。

我的信念是,它基本上取决于这样一个事实:您总是在构建数据的二级表示(即覆盖“对象”)。在大多数命令式或(非对象)函数式语言中,不太可能构建如此大的、语义无关的数据二级表示。如果要在这个世界上建立一个二级代表,它更有可能是一个 抽象化 某种类型的这与我的一个基本(未经证实的)信念相对应,即OOP范式基本上就是众所周知的锤子,它使每个问题看起来都像钉子。

ORM中的主要问题不是处理简单的特性,比如将列“x”映射到结构字段“x”。这可以通过几个技巧(宏、代码生成、反射等)完成。

问题是如何处理OOP特性,如继承、组合、引用、对象唯一性、接口等。从这个意义上讲,继承是一个婊子,因为它作为多个表的简单实现不是最佳的。

你有两个障碍不匹配。

1. 记录到对象。
2. 您的SQL查询语言。

虽然第一个障碍不匹配可能不适用于所有非OOP语言,但第二个障碍在所有语言中都是外观的,可以使用DSL解决。 as seen here