repository - DDD : Repositories are in-memory collections of objects?

Question

我注意到 Repository 通常通过以下任一方式实现:

方法一

void Add(object obj);
void Remove(object obj);
object GetBy(int id); 

方法二

void Save(object obj);     // Used both for Insert and Update scenarios
void Remove(object obj);
object GetBy(int id);

方法 1 具有集合语义(这是定义存储库的方式)。我们可以从存储库中获取一个对象并对其进行修改。但是我们不会告诉集合更新它。以这种方式实现存储库需要另一种机制来持久化对内存对象所做的更改。据我所知，这是使用工作单元完成的。但是，有些人认为只有在系统中需要事务控制时才需要 UoW。

方法 2 消除了对 UoW 的需要。您可以调用 Save() 方法，它会确定对象是新的并且应该被插入或被修改并且应该被更新。然后它使用数据映射器将更改持久化到数据库。虽然这让生活变得更轻松，但建模的存储库没有集合语义。该模型具有 DAO 语义。

我真的很困惑。如果存储库模仿内存中的对象集合，那么我们应该根据方法 1 对它们进行建模。

你对此有何看法？

莫什

Answer 1

我个人认为工作单元模式作为解决方案的一部分没有问题。显然，您只需要它用于 CRUD 中的 CUD。但是，您正在实现 UoW 模式这一事实只不过表明您有一组需要作为批处理进行的操作。这与说它需要成为交易的一部分略有不同。如果你足够好地抽象你的存储库，你的 UoW 实现可能与你正在使用的支持机制无关 - 无论是数据库、XML 等。

至于具体问题，我认为方法一和方法二之间的区别是微不足道的，如果没有其他原因，方法二的大多数实例都包含检查是否设置了标识符。如果设置，则视为更新，否则视为插入。在我看来，这个逻辑通常内置在存储库中，更多的是为了简化公开的界面。存储库的目的是在消费者和数据源之间代理对象，并消除直接了解数据源的必要性。我使用方法二，因为我相信检测标识符的简单逻辑，而不是依赖于整个应用程序中的跟踪对象状态。

存储库使用的术语与数据访问和对象集合如此相似，这一事实导致了混淆。我只是将他们视为自己的一等公民，并为该领域做最好的事情。 ;-)