工作单元和存储库模式做错了吗？答案

【问题标题】：Unit Of Work and Repository pattern done wrong?工作单元和存储库模式做错了吗？
【发布时间】：2015-06-29 13:26:13
【问题描述】：

我在网上看到很多存储库模式的例子，签名如下或类似：

public void IRepository<T>
{
    void Insert(T object);
    void Update(T object);
    void Delete(T object);
    T GetById(int id);
    IEnumerable<T> GetAll();
}

令我困惑的是，为什么 CUD 元素是存储库模式的一部分？根据Martin Fowler，CUD 操作应该是工作单元模式的一部分。

多年来，我一直在 EF 中使用 Fowler 的方法，并且效果很好。我认为它适用于任何其他 ORM。

如果有人能从架构和逻辑的角度解释为什么我们应该将 CUD 操作放在存储库模式中，我很感兴趣？很明显，这两种方法都有效，但我们为什么要选择另一种呢？ Fowler 的风格不是更符合 CQRS 精神吗？

【问题讨论】：

标签： repository-pattern unit-of-work cqrs

【解决方案1】：

如您提供的链接中所述，工作单元会跟踪数据库中发生的更改。它保持跟踪，不更新。最后，它会计算出由于您的工作而改变数据库需要做的所有事情（引用您的链接）。提交工作单元归结为调用（通常是多个）存储库以一次性完成实际的 CUD 操作

【讨论】：

这仍然不能解释为什么存储库模式有 CUD 操作。他们的目的是什么？正如您所说，UoW 跟踪对数据库的更改并在单个事务中提交它们（UoW 的另一个特性）。那么，为什么我需要在存储库模式中使用它们？他们在那里的目的是什么？
如果您没有存储库，您将如何将更改提交到实际数据库？您的 UoW 会知道 JDBC 或 JPA 还是会在底层持久性发生变化时发生变化？这与 UoW 完全不同，由 Repository 处理。 UoW 不讨论 JDBC，它将其留给 Repository。
对不起，我对 JDBC 不熟悉。我是微软老兄:)。我认为它们是连接到数据库并从中读取和写入的手段。现在，如果 UoW 跟踪数据库的更改，为什么它不应该知道数据库？否则，它将如何跟踪更改并将其提交到数据库？
嗯，这就是重点。 UoW 知道什么但不知道如何。存储库知道如何。当然，你可以让 UoW 知道如何连接数据库，也可以做用户输入验证，也许还有一些业务逻辑，为什么不呢？