也许这是一个答案微不足道的问题，但尽管如此，它还是让我发疯了几天，所以我想听到一个答案。我最近查找了大量与为自己的项目构建自定义数据映射器(而不是使用 ORM)相关的信息，并阅读了 stackoverflow 或其他网站上的几个线程。
对我来说，拥有 AuthorCollection 对象似乎非常有说服力，这些对象基本上只是 Author 实例或 BookCollection 对象的容器，其中包含多个 Book 实例。但为什么单个 Author 对象需要一个映射器呢？我能想到的所有获取条件(除了要求具有指定 BookID 或 AuthorID 的对象的条件除外)将返回多个 Book 或 Author 实例，因此是 BookCollection 或 AuthorCollection 实例。那么，如果相应集合的映射器更通用并且您不必确保您的条件只会返回一个结果，为什么还要为单个对象使用映射器呢？
预先感谢您的帮助。
最佳答案
简短回答
您无需为 Author 和 AuthorCollection 创建两个映射器。如果您的程序不需要 AuthorMapper 和 AuthorCollectionMapper 来顺利工作并拥有干净的源代码，无论如何，请按照您最习惯的方式进行操作。
Note: Choosing this route means you should be extra careful looking out for SRP violations.
长(呃)答案
这完全取决于您想要做什么。为了这篇文章的目的，我们将 AuthorMapper 称为项目数据映射器，将 AuthorCollectionMapper 称为集合数据映射器。
通常，项目映射器不会像其集合映射器那么复杂。项目映射器通常仅通过主键获取，因此限制了结果，从而使映射器因其他特定于集合的内容而变得干净整洁。
我提出的这些“特定于集合的事物”的一个主要部分是条件1以及它们如何在查询中实现。通常，在集合映射器中，您可能会遇到比项目数据映射器中通常更高级、更长且乏味的查询。尽管完全有可能将平均项目数据映射器查询 (SELECT ... WHERE id = :id) 与复杂的集合映射器查询相结合无需使用臭条件2，它会变得更加复杂，并且当数据库需要的只是一个简单的通用查询时，仍然会困扰数据库执行冗长的查询。
此外，尽管您指出使用项目映射器我们实际上只能通过主键获取，但使用项目映射器处理其他事情通常会变得更加简单。项目映射器的 save() 和 remove() 方法可以比尝试使用集合映射器保存/删除项目更好地处理(使用正确的实现)作业。而且，除此之外，很明显，在使用集合映射器的 save() 和 remove() 方法的过程中，集合映射器有时可能希望利用项目映射器方法。
针对您的以下问题，您可能多次需要设置条件来从数据库中删除行集合。例如，您可能有一个垃圾邮件标志，设置后会隐藏帖子，但会在三十天内自毁。在这种情况下，您很可能有一个垃圾邮件标志条件和一个时间范围条件。另一种可能是在删除答案三十天后删除答案下的所有评论。我提到三十天是因为至少将这些数据保留一段时间是明智的，以防万一有人想要他们的评论，或者事实证明带有垃圾邮件标志的行实际上不是垃圾邮件。
1. Condition here means a property set on the collection instance which the collection mapper's query knows how to handle. If you haven't already, check out @tereško's answer here.
2. This condition is different and refers to the "evil if" people speak of. If you don't understand their nefariousness, I'd suggest watching some Clean Code Talks. This one specifically, but all are great.
关于PHP datamapper - 为什么将它们用于非集合对象？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17431127/