jbl*_*lue 12 mysql database orm design-patterns datamapper
我遇到了几个最近宣布他们计划将他们的实现从Active Record转移到Data Mapper的ORM.我对这个主题的了解非常有限.对于那些了解得更好的人来说,问题是Data Mapper比Active Record更新吗？当Active Record运动开始时它是否存在？两者如何联系在一起？
最后,由于我不是一个数据库人,对这个主题知之甚少,我是否应该遵循正在转向Data Mapper实现的ORM,就像我作为编写软件的人(不是数据人)的内容一样？
Gor*_*don 28
DataMapper不是更现代或更新,但更适合ORM.
人们改变的主要原因是因为ActiveRecord 不能提供良好的ORM.AR 在数据库表或视图中包装行,封装数据库访问,并在该数据上添加域逻辑.因此,根据定义,AR是数据库记录的1:1表示,这使得它特别适用于简单的CRUD.
一些AR增加了相关数据的获取,这使人们相信AR是一个ORM.它不是.ORM的要点是解决数据库结构和域对象之间的对象关系阻抗不匹配问题.使用AR时,您无法解决此阻抗不匹配问题,因为您的AR代表数据库行而不是正确的OO设计.您正在将数据库布局绑定到对象.一些对象关系行为模式仍然可以应用(例如延迟加载).
AR经常受到批评的另一个原因是它混淆了两个问题:业务逻辑和数据库访问逻辑.这导致不希望的耦合,并且可能导致较大应用中较少的可维护性和灵活性.两层之间没有隔离.耦合总是导致灵活性降低.
甲DataMapper的另一方面的目的和同时保持它们彼此独立,并映射器本身的数据库之间移动数据.虽然更难实现,但它允许在您的应用程序中进行更灵活的设计.您的域对象不再必须与db结构匹配.DAL和域层是分离的.
Pet*_*sko 18
即使该帖子已有 8 年历史，但该问题在 2018 年仍然有效。
Active Record 是Anti 模式，请注意这一点。它在代码和数据库之间创建了一个非常紧密的耦合。对于小型简单项目来说，这可能不是问题。但是，我强烈建议避免在更大的地方使用它。
一个好的 OOP 设计是分层完成的。输入层、服务层、存储库层、数据映射器和数据库——只是一个简单的例子。您不应该将输入层与数据库混合。如何做到这一点？例如，在 Laravel 中，您可以使用这样的 Validator 规则：
'email' => 'exists:staff,email'
它检查表人员中是否存在电子邮件。这是一个完整的 OOP 废话。它使用 DB 列名称收紧您的顶层。我无法想象有任何更好的例子来说明糟糕的 OOP 设计。
底线 - 如果您正在创建一个包含 2-3 个表的简单站点，例如博客，活动记录可能不是问题。对于任何更大的事情，请使用 Data Mapper 并注意 OOP 原则，例如 IoC、SoC 等。