Data Mapper 是否比 Active Record 更现代的趋势？

Posted 2023-03-31

【中文标题】Data Mapper 是否比 Active Record 更现代的趋势？

【英文标题】：Is Data Mapper a more modern trend than Active RecordData Mapper 是不是比 Active Record 更现代的趋势？

【发布时间】：2011-04-19 04:49:19

【问题描述】：

我遇到了几个 ORM，它们最近宣布他们计划将其实施从 Active Record 转移到 Data Mapper。我对这门学科的了解非常有限。那么对于那些更了解的人来说，一个问题是，Data Mapper 是否比 Active Record 更新？ Active Record 运动开始时就在附近吗？两者是如何联系在一起的？

最后，由于我不是数据库人员并且对这个主题知之甚少，我是否应该遵循一个正在迁移到 Data Mapper 实现的 ORM，就像作为编写软件的人（不是数据人员）对我来说有什么意义？

【参考方案1】：

DataMapper 不是更现代或更新，而是更适合 ORM。

人们改变的主要原因是因为ActiveRecorddoes not make for a good ORM。 AR在数据库表或视图中包装一行，封装数据库访问，并在该数据上添加域逻辑。所以根据定义，AR 是数据库记录的 1:1 表示，这使得它特别适合简单的 CRUD。

一些 AR 增加了相关数据的获取，这使人们认为 AR 是一种 ORM。它不是。 ORM 的重点是处理数据库结构和域对象之间的object relational impedance mismatch。使用 AR 时，您无法解决这种阻抗不匹配问题，因为您的 AR 代表数据库行而不是正确的 OO 设计。您正在将您的数据库布局与您的对象联系起来。一些对象关系行为模式仍然可以应用（例如延迟加载）。

AR 经常受到批评的另一个原因是因为它混合了两个问题：业务逻辑和数据库访问逻辑。这会导致不必要的耦合，并可能导致大型应用程序的可维护性和灵活性降低。两层之间没有隔离。耦合总是会导致灵活性降低。

另一方面，DataMapper 在对象和数据库之间移动数据，同时保持它们彼此独立以及映射器本身。 虽然更难实现，但它允许更灵活的设计在您的应用程序中。您的域对象不再需要匹配 db 结构。 DAL 和 Domain 层是解耦的。

【参考方案2】：

虽然帖子已经 8 年了，但问题在 2018 年仍然有效。

活动记录是反模式注意这一点。它在代码和数据库之间创建了非常紧密的耦合。对于小型简单项目来说，这可能不是问题。但是，我强烈建议避免在更大的情况下使用它。

一个好的 OOP 设计是分层完成的。输入层、服务层、存储层、数据映射器和数据库——只是一个简单的例子。您不应将输入层与数据库混合。如何做到这一点？例如，在 Laravel 中，您可以使用这样的验证器规则：

'email' => 'exists:staff,email'

它检查电子邮件是否存在于表人员中。 这是一个完全的 OOP 废话。它使用 DB 列名称紧贴您的顶层。我想不出任何更好的糟糕 OOP 设计的例子。

底线 - 如果您要创建一个包含 2-3 个表的简单站点，例如博客，活动记录可能不是问题。对于更大的事情，请使用 Data Mapper，并注意 IoC、SoC 等 OOP 原则。

【讨论】：

我强烈反对 Active Record 是一个反模式。最后，这一切都归结为开发人员在很长一段时间内的生产力。我曾使用过 SQLAlchemy（一个 Data Mapper ORM）和 Django ORM（一个 Active Record ORM）。 我使用 Django ORM 的工作效率更高，尽管我对它的经验较少。我通常不需要编写复杂的逻辑，只需要简单的 CRUD 查询。 Django ORM 使这变得简单易读。另外，Django 也不小。与 Flask 一起，它是 Python 中最常用的 Web 框架。所以我可能不是唯一一个有这种感觉的人。

好吧，实现快捷方式和反模式总是从“在这种情况下会更简单”开始，然后随着应用程序的增长而适得其反。 Laravel 的活跃记录在很多层面上都是错误的..