ORM、AR、QB 和 DM 之间有什么区别？

Question

好的，所以每个人都认为（并且有充分的理由）严格的 SQL 是魔鬼。这给我们留下了许多在代码中放置“中间人”以将代码与数据库分开的方法。我现在要把我收集到的所有信息都吐出来，希望有人可以让我束手无策，告诉我我建造了什么。

ORM（对象关系映射）是一系列工具（松散或紧密集成的依赖），可将数据库行映射到应用程序中的对象。

在 AR（Active-Record）中是一种 ORM，其中数据库表或视图被包装到一个类中，因此对象实例被绑定到表中的单行。

数据映射 (DM) 是一种 ORM，它是在两个不同数据模型之间创建数据元素映射的过程。

这三个都声称是这样工作的：

$user = new User();
$user->name = 'Fred';
$user->save();

通常使用类似这样的 User 类：

class User extends Model {
    // Specify the database table
    protected $table = "users";

    // Define your fields
    protected $fields = array(
        'id' => array('type' => 'int', 'primary' => true),
        'name' => array('type' => 'string', 'required' => true),
        'email' => array('type' => 'text', 'required' => true)
    );
}

通过此设置，您无需编写 SQL 即可轻松获取行。

// users
$users = $user->fetch(array('id' => 3));

一些 AR 类实际上看起来更像这样：

$db->where('id' => 3);
$db->join('posts', 'posts.user_id = users.id');
$results = $db->get('users');

好的，现在这是它变得毛茸茸的地方。对于什么类型的代码落在哪里，每个人和他的兄弟似乎都有不同的看法。虽然大多数人都同意 AR 或 DM 是一种 ORM - 但有时区分 AR 和 DM 的线条似乎模糊不清。

我编写了一个使用单个对象 ($db) 的类，您可以在其中调用该对象并处理 SQL 创建以保存/获取结果。

//Fetch the users
$results = $db->select('id, name')->where('id > 4')->get('users');

//Set them active
while($user = $results->fetch()) {
    $user->active = TRUE;
    $user->save();
}

所以问题是“它是什么？”，为什么人们不同意这些条款？

Answer 1

并不是说直接的 SQL 就是魔鬼——有时几乎需要编写原始 SQL 才能让查询以您想要的方式执行。对我来说，ORM 比其他任何东西都更能消除手工工作（比如不惜一切代价避免 SQL）。我只是不想为每个项目设置所有手动查询的代码对象。这只是一个荒谬的工作和想法。相反，ORM 工具提供了一种很好的自动化方式来创建需要大量手动工作的数据对象。现在我可以拥有可以扩展和创建自定义函数的自动单个行对象，而无需考虑它。我可以从不同的表中检索相关的行，而无需手动编写查询代码。

看起来您的 User 类示例来自 phpDataMapper，如果是这样，它还具有其他一些内置细节，例如自动表迁移，因此您不必为表结构分发 SQL 文件作为一些辅助功能和其他东西。包含的所有功能旨在节省您的时间 - 这是主要目标。

AR 和 DM 之间最重要的区别是 ActiveRecord (AR) 行知道它自己的数据存储，因此在每个行对象上都有保存/更新功能 - $user->save() - “记录”活跃”。另一方面，使用 DataMapper (DM)，根据定义，每个单独的行都不知道它自己的数据存储。该行更像是一个可以在您的代码中使用的哑值对象。映射器负责将对该行的更改转换回数据存储区 - $mapper->save($user)。这是最显着的区别——您会发现大多数核心 ORM 功能在几乎任何实现中都是相同的。这主要取决于如何在核心架构级别组合在一起。

Answer 2

同意@Aiden Bell。但我认为你指出差异是正确的。我使用 LINQ to SQL，在您的定义中它只是 ORM 的 Active-Record 样式。对我来说，这很好用，因为我在处理许多未开发的应用程序并从数据库开始构建我的课程。从那里我倾向于遵循领域驱动设计方法（我知道......这是一个类优先的概念）与我生成的类一起工作。对我来说，这让我很快就能上路。

话虽如此，我还使用过 Entity Framework 和 Nhybernate。 Entity Framework 是 UBER 数据映射器，NHybernate 也是一个数据映射器，但没有那么复杂！我个人觉得Entity Framework还有很长的路要走。如果我需要更多的复杂性，比如在一个棕地应用程序中，数据库相当固定，我需要让我的类来代表我的应用程序而不是我的数据库，那么我宁愿转向更多类似的东西Nhybernate 及其数据映射功能。

我认为这些工具中的每一个都有它的位置。说它们全都一样是不公平的。活动记录很棒，因为它为我生成了直接代表我的数据库的类。这在我创建数据库或数据库密切代表我无处不在的应用程序术语和概念时有效。当我有一个没有意义或明确映射到我的应用程序的固定数据库时，orms 的映射类型起作用，在这种情况下，我可以封装数据库中的复杂性或缺乏复杂性，以通过映射功能创建丰富的域ORM 工具。

Answer 3

您不妨编造首字母缩略词 ORM、RM DM 等等……这一切都只是状态从一种媒介转移到另一种媒介并包装在函数/语义中.

Sun Microsystems 和 Microsoft 一直使用 Java 和 C# 来做这件事。让我们取一个简单的东西，给它一个新名字！真是个好主意。

如果你说 ORM .. 每个人都知道它是什么，有很多形式。不过，您的代码看起来像 Linq 的东西。

没有魔法，但有很多流行语和大惊小怪的恕我直言。