我遇到了几个最近宣布他们计划将他们的实现从Active Record转移到Data Mapper的ORM . 我对这个主题的了解非常有限 . 对于那些了解得更好的人来说，问题是Data Mapper比Active Record更新吗？当Active Record运动开始时它是否存在？两者如何联系在一起？
最后，由于我不是一个数据库人，对这个主题知之甚少，我是否应该遵循正在转向Data Mapper实现的ORM，就像我作为编写软件的人（不是数据人）的内容一样？
DataMapper不是更现代或更新，但更适合ORM .
人们改变的主要原因是ActiveRecord does 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和域层是分离的 .
尽管该帖子已有8年历史，但这个问题在2018年仍然有效 .
活跃的记录是 Anti pattern 提防 . 它在代码和数据库之间创建了非常紧密的耦合 . 对于小型简单项目来说，这可能不是问题 . 但是，我强烈建议避免在任何更大的地方使用它 .
良好的OOP设计分层完成 . 输入层，服务层，存储库层，数据映射器和数据库 - 只是一个简单的例子 . 您不应将输入图层与数据库混合使用 . 怎么做到这一点？例如，在Laravel中，您可以使用如下的Validator规则：
'email' => 'exists:staff,email'
它检查表格中是否存在电子邮件 . 这是一个完整的OOP无意义 . 它使用DB列名称来压缩顶层 . 我无法想象任何糟糕的OOP设计的更好的例子 .
底线 - 如果您要创建一个包含2-3个表的简单站点，如博客，Active记录可能不是问题 . 对于任何更大的东西，请使用Data Mapper并注意OOP原则，如IoC，SoC等 .
2 回答
DataMapper不是更现代或更新，但更适合ORM .
人们改变的主要原因是ActiveRecord does 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和域层是分离的 .
尽管该帖子已有8年历史，但这个问题在2018年仍然有效 .
活跃的记录是 Anti pattern 提防 . 它在代码和数据库之间创建了非常紧密的耦合 . 对于小型简单项目来说，这可能不是问题 . 但是，我强烈建议避免在任何更大的地方使用它 .
良好的OOP设计分层完成 . 输入层，服务层，存储库层，数据映射器和数据库 - 只是一个简单的例子 . 您不应将输入图层与数据库混合使用 . 怎么做到这一点？例如，在Laravel中，您可以使用如下的Validator规则：
它检查表格中是否存在电子邮件 . 这是一个完整的OOP无意义 . 它使用DB列名称来压缩顶层 . 我无法想象任何糟糕的OOP设计的更好的例子 .
底线 - 如果您要创建一个包含2-3个表的简单站点，如博客，Active记录可能不是问题 . 对于任何更大的东西，请使用Data Mapper并注意OOP原则，如IoC，SoC等 .