我遇到了几个 ORM，它们最近宣布他们计划将其实施从 Active Record 转移到 Data Mapper。我对这门学科的了解非常有限。那么对于那些更了解的人来说，一个问题是，Data Mapper 是否比 Active Record 更新？ Active Record 运动开始时就在附近吗？两者是如何联系在一起的？
最后，由于我不是数据库人员并且对这个主题知之甚少，我是否应该遵循一个正在迁移到 Data Mapper 实现的 ORM，就像作为编写软件的人（不是数据人员）对我来说有什么意义？
【问题讨论】：
标签： mysql database design-patterns orm datamapper
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 层是解耦的。
【讨论】：
虽然帖子已经 8 年了，但问题在 2018 年仍然有效。
活动记录是反模式注意这一点。它在代码和数据库之间创建了非常紧密的耦合。对于小型简单项目来说，这可能不是问题。但是，我强烈建议避免在更大的情况下使用它。
一个好的 OOP 设计是分层完成的。输入层、服务层、存储层、数据映射器和数据库——只是一个简单的例子。您不应将输入层与数据库混合。如何做到这一点？例如，在 Laravel 中，您可以使用这样的验证器规则：
'email' => 'exists:staff,email'
它检查电子邮件是否存在于表人员中。 这是一个完全的 OOP 废话。它使用 DB 列名称紧贴您的顶层。我想不出任何更好的糟糕 OOP 设计的例子。
底线 - 如果您要创建一个包含 2-3 个表的简单站点，例如博客，活动记录可能不是问题。对于更大的事情，请使用 Data Mapper，并注意 IoC、SoC 等 OOP 原则。
【讨论】：