Data Mapper是比Active Record更现代的趋势吗？
我遇到了几个ORM，他们最近宣布他们计划将其实施从Active Record迁移到Data Mapper。 我对这个问题的了解非常有限。 那么对于那些了解更好的人来说，Data Mapper比Active Record更新？ 当活动记录运动开始时，它到了吗？ 这两者如何关联在一起？
最后，因为我不是一个数据库人员，并且对这个主题知之甚少，我是否应该遵循一个正在转向Data Mapper实现的ORM，就像有人在写软件（而不是数据人员）时那样？
DataMapper不是更现代或更新，但更适合于ORM。
人们改变的主要原因是因为ActiveRecord没有提供一个好的ORM。 AR将数据包封装在数据库表或视图中，封装数据库访问，并在该数据上添加域逻辑。 因此，根据定义，AR是数据库记录的1：1表示，这使得它特别适合于简单的CRUD。
有些人向他们的AR添加了相关数据，这让人们相信AR是一个ORM。 不是这样。 ORM的要点是解决数据库结构和域对象之间的对象关系阻抗不匹配问题。 当使用AR时，由于您的AR代表数据库行而不是适当的OO设计，因此您没有此阻抗不匹配。 你将你的数据库布局绑定到你的对象上。 一些对象关系行为模式仍然可以应用（例如延迟加载）。
AR经常受到批评的另一个原因是因为它混淆了两个问题：业务逻辑和数据库访问逻辑。 这会导致不必要的耦合，并可能导致较大应用程序的可维护性和灵活性较低。 两层之间没有隔离。 联轴器总是导致较少的灵活性。
另一方面，DataMapper在对象和数据库之间移动数据，同时保持它们彼此独立，并保持映射器本身的独立性。 虽然实现起来比较困难，但它可以在应用程序中实现更灵活的设计。 您的域对象不再需要匹配数据库结构。 DAL和域层是分离的。
我的2美分：
DataMapper比ActiveRecord更新。 我更喜欢DataMapper的语法; 它更加明确，不那么“神奇”。 我可以通过更多的理由，但他们在这里列出：http://datamapper.org/why
ActiveRecord有更多的文档。
尽管这个职位是8岁，但问题仍然在2018年有效。
有效的记录是反模式小心那。 它在代码和数据库之间创建了非常紧密的耦合。 对于小型简单项目来说，这可能不成问题。 不过，我强烈建议避免将它用于更大的任何东西。
一个好的OOP设计是分层完成的。 输入层，服务层，存储库层，数据映射器和数据库 - 只是一个简单的例子。 你不应该混合输入层和数据库。 如何做到这一点？ 例如，在Laravel中，您可以使用如下所示的Validator规则：
'email' => 'exists:staff,email'
它检查电子邮件是否存在于表格工作人员中。 这是一个完整的OOP无意义。 它使用数据库列名紧缩顶层。 我无法想象一个糟糕的面向对象设计的更好的例子。
底线 - 如果您正在创建一个包含2-3个表格的简单网站，例如博客，则活动记录可能不成问题。 对于任何更大的内容，请使用Data Mapper并小心OOP原则，例如IoC，SoC等。
链接地址: http://www.djcxy.com/p/96047.html