我真的不相信对象关系阻抗不匹配?

对象-关系不匹配的概念来自于尝试使用由关系数据库支持的面向对象编程方法时出现的问题。问题产生于这样一个事实:对象模型通常包含对象的层次结构,这些对象需要分解成多个表并从中重建,而不是将对象作为一个整体存储。

然而,通常在这一点上出现的论点是,如果你没有发现问题,那就是你的错,因为你没有做“正确”的对象方向,而且当你学会“正确”的对象方向时,你会发现不匹配。我们都知道,面向对象是唯一“合适”的开发模式。

哦,等等。

许多系统不适合被建模为面向对象的系统。事实上,对于Web应用程序这样的应用程序,如果其总体复杂度较低(局部复杂度较高),并且需要较高的并发性和可伸缩性,那么使用面向服务和消息传递技术可能是更好的选择。当以这种方式编写应用程序时,您会发现对象关系不匹配的情况并不多,因为您不使用诸如延迟加载和复杂的对象层次结构之类的东西,并且您的对象是不可变的,因此不需要将它们分割回数据库。

那么是否存在对象-关系不匹配?是的,如果您尝试在关系数据库中使用面向对象技术。但是,如果其他方法更适合您的应用程序,您可以通过不使用面向对象技术来减轻它。

对象关系阻抗失配是关系数据库与面向对象软件模型之间的差异造成的。如果您没有看到任何不匹配,那是因为您的代码没有真正正确地执行OO。

当您开始正确地执行OO,并尝试将这些关系映射到RDBMS时,您将了解问题所在。

如果您的域模型很简单,并且没有深度继承,那么您可能永远不会感觉到阻抗不匹配。

例如,假设类foo定义了属性foo。bar子类foo,并引入属性bar。如何在数据库中存储foos和bars?

您可以有一个包含字段foo和bar的表foo…每个foo都会满足“bar is null”。但是如果你的子类引入了一大堆属性,那是浪费。

所以也许你有两张桌子,Foo和Bar。是否将foo中的所有列复制到bar中,以便在一个select中加载整个bar?或者你必须加入FOO和BAR才能加载BAR?

阻抗指的是这样一个事实,即你必须考虑到所有这些小细节,即你如何将一个物体“切碎”(使用greg-beech的术语)成一个或多个表格。