数据持久层需要多少个抽象级别？

Question

我正在使用 DDD 技术编写一个应用程序。这是我第一次尝试 DDD 项目。这也是我的第一个绿地项目，我是唯一的开发商。我已经充实了域模型和用户界面。现在我从持久层开始。像往常一样，我从单元测试开始。

[Test]
public void ShouldAddEmployerToCollection()
{
    var employerRepository = new EmployerRepository();
    var employer = _mockery.NewMock<Employer>();

    employerRepository.Add(employer);
    _mockery.VerifyAllExpectationsHaveBeenMet();
}

正如您所看到的，我没有写出对 Add() 函数的任何期望。到目前为止，我意识到我还没有选定特定的数据库供应商。事实上，我什至不确定它是否需要数据库引擎。平面文件或 xml 可能同样合理。所以我想知道我的下一步应该是什么。

我应该添加另一层抽象吗...例如 DataStore 接口还是寻找已经为我完成工作的现有库？如果可以的话，我想避免将程序与特定的数据库技术联系起来。

Answer 1

根据您的要求，您真正需要的唯一抽象是具有基本 CRUD 语义的存储库接口，以便您的客户端代码和协作对象仅处理 IEmployerRepository 对象而不是具体存储库。您有几种选择：

1）不再抽象。只需在您需要的顶级应用程序中构建具体的存储库即可：

IEmployeeRepository repository = new StubEmployeeRepository();
IEmployee           employee   = repository.GetEmployee(id);

在一百万个地方进行更改将会过时，因此该技术仅适用于非常小的项目。

2) 创建要在应用程序中使用的存储库工厂：

IEmployeeRepository repository = repositoryFactory<IEmployee>.CreateRepository();
IEmployee           employee   = repository.GetEmployee(id);

您可以将存储库工厂传递到将使用它的类中，或者您可以创建一个应用程序级静态变量来保存它（它是一个单例，这是不幸的，但相当有限）。

3）使用依赖注入容器（本质上是通用工厂和配置机制）：

// A lot of DI containers use this 'Resolve' format.
IEmployeeRepository repository = container.Resolve<IEmployee>();
IEmployee           employee   = repository.GetEmployee(id);

如果您以前没有使用过 DI 容器，那么这里有很多关于它们的很好的问题和答案（例如 哪些 C#/.NET 依赖注入框架值得正在调查？和数据访问、单元测试、依赖注入 ），并且您肯定想阅读 Martin Fowler 的 控制容器反转和依赖注入模式 ）。

Answer 2

在某些时候，您将必须调用您的存储库将如何处理数据。当您开始项目时，最好使其尽可能简单，并且仅在必要时添加抽象层。在这个阶段，简单地定义您的存储库/DAO 可能就足够了。

通常，存储库/存储库/DAO 应该了解您决定使用哪个数据库或 ORM 的实现细节。我想这就是您在 DDD 中使用存储库的原因。这样您的测试就可以模拟存储库并且不知道实现。

Answer 3

我写了一篇关于在 NHibernate 之上实现存储库模式的博客文章，我认为无论您是否使用 NHibernate，它都会使您受益。

创建一个通用的通用和可扩展的NHiberate存储库

Answer 4

我在持久层中发现的一件事是确保有一个地方可以开始进行抽象。如果数据库不断增长，您可能需要开始实施分片，除非已经有可用的抽象层，否则以后添加抽象层可能会很困难。

Answer 5

我相信您不应该仅仅为了单元测试的目的而在存储库类下面添加另一层，特别是如果您没有选择持久性技术。我认为您无法在不公开有关持久性方法的详细信息的情况下创建比“repository.GetEmployee(id)”更精细的接口。

如果您确实考虑使用纯文本或 XML 文件，我相信最好的选择是坚持使用存储库接口抽象。但是，如果您决定使用数据库，并且不确定供应商，那么 ORM 工具可能是您的最佳选择。