在域驱动设计中，存储库模式是否维护对对象的引用？

Question

我了解到，存储库模式抽象了域对象的持久性，使开发人员可以从持久性存储中读取/写入/删除对象，而无需知道对象的存储方式（SQL，NoSQL，平面文件等）。 我非常喜欢存储库模式，并发现它在许多情况下都能很好地工作，例如，从持久性逻辑中抽象业务逻辑，允许在适当的地方延迟加载对象等。

但是，我不清楚的是存储库对象是否维护对所有对象的引用？ 例如：

Repository repository;
std::shared_ptr<Person> pPerson = repository.retrievePersonById("bob");

p->updateDetails("Bob", "the Builder");
repository.savePerson(p);

1. 在上述假设的C ++示例中， repository是否应该维护对返回的Person实例的引用？ 是的-感谢Guillaume31的内存类比 。
2. 如果对Q1的回答为“是”，则repository应在何时以及如何删除该Person实例？ 大概是参考计数达到零时。
3. 如果对Q1的回答为“否”，那么当另一个区域想要访问同一对象，但是由于repository不再存储对其的内部引用，它将如何处理来自数据库的新副本，从而如何处理，您将如何处理？当您真的应该引用同一个实例时，有两个Person实例？ 假设对Q1的回答为“是”，那么存储库将始终维护引用，因此应始终返回相同的对象 。

尽管上面的示例在C ++中，但实际上我在写一个PHP应用程序。

Answer 1

对于存储库更合适的隐喻可能是它是对象的内存中集合的错觉。 从任何OO语言获取您的基本集合类型。 如果从该集合中获取一个元素并进行修改，则通常不必再将其保存回该集合中，因为它从未停止过出现在该集合中。

存储库也是如此-它提供对象，可以向其自身添加对象，但是不公开任何用于将修改保存到基础存储的功能。 确实，这都是隐藏基础存储的存在。 它也不公开任何方法来“更新”实体的状态，因为它所服务的实体位于内存中，并且您可以自由地对其进行修改，因此它永远不会同步。

如果存储库不进行事务管理和提交工作单元，那也更好。 您应将其委托给客户端（请参见第156页的域驱动设计）。

要回答您的问题，在业务交易中，您不应假设任何有关存储库返回的对象新鲜度的信息。 它们只是反映某些实体在某个时间点的状态，您要做的就是照原样使用它们。 在更全球化的水平上，某些外部机制（通常是ORM工具）将为您提供管理通常如何以工作单元实施的形式将您的小企业交易与其他交易隔离的能力。 冲刷数据库更改和处理潜在的陈旧实体问题不是每个存储库查询决定，而是更具全局性的业务事务级别决定，仅当您确定用例完成并想要提交时才应该执行。