Design patterns 数据映射器模式与存储库模式有何不同？

我发现两种模式似乎有着相同的目标——有什么不同

[存储库]是映射的另一个抽象层 查询构造代码集中的层

DataMapper

确保隔离墙的DB端不需要知道业务逻辑的细节以及业务对象如何将数据保存在内存中，隔离墙的业务端也不需要知道数据是如何存储的

以说明，考虑您的数据作为一行集合保存在数据库中，表示每行代表存储中的一个项目。在内存中，您可能不希望将该信息保存为

StoreItem

列表，而是将其保存为两个列表，一个用于库存项目，另一个用于缺货项目。 处理一个列表和两个列表之间的转换将是数据映射器的工作

通过在业务方面添加其他对象和继承的列表，您可以使事情复杂化。“DataMapper”必须转换到关系数据库，并从该表示转换到关系数据库

“存储库”向业务端提供了“从表中选择*条件”功能。您提供一个筛选器，它将返回与该筛选器匹配的对象集合

---

简而言之：“DataMapper”处理单个对象，“Repository”处理对象集合，并扩展“DataMapper”提供的功能。

如果数据映射器太大或处理的查询量比实际映射对象大，则可以引入另一个类来专注于单独查询部分，您可以将其命名为存储库模式。很好的解释，您能举一个例子说明这些模式的不同之处吗。从我在Java、.NET和PHP框架中看到的情况来看，这两个概念似乎可以互换使用，这非常令人困惑。@LordYggdrasill如果您对某个特定框架有特定问题，您应该在本网站上以问题的形式提出。查询和映射是逻辑上不同的任务，但它们的实现常常紧密耦合，这可能解释了为什么一些（引用的）可能会选择将它们考虑在一起。如您所见，他们的存储库模式实现看起来与POEAA中Martin Fowler的数据映射器完全相同。你知道如何解释这种现象吗？也许ASP.NET的存储库实际上是一个数据映射器@LordyGdrasill存储库处理查询。这并不意味着，如果一个类不进行查询，它就不是一个存储库，而是说，如果一个类提供查询，那么它就是一个存储库。在示例链接中，数据映射部分被委托给DbSet。福勒的作品不是经文，你可以选择忽略它们或将它们解释为最适合你的应用（尽管你不应该）。如果您有其他问题，请单独发布一个问题。一个2年问题的评论部分不是讨论的地方。我不知道谁负责解决关系。假设我想获取一个

列表

，每个

订阅

都有一个

列表

。我可以获取存储库层中的所有数据并将其返回，但存储库不会执行实际上是映射层的工作吗？