实体框架、存储库模式、工作单元和测试

Question

所以我一直在尝试重新设计我最近投入生产的项目中的数据访问。

我开始阅读有关存储库和工作单元模式的内容，这让我很感兴趣。我以前从未使用过 TDD，但我想我可以试一试。

我的工作并不重要，所以对我来说，更好地了解更多的是一种爱好。

我有一些工作，但想看看我是否完全错过了标记。这就是我所拥有的......（为简单起见，我将使用 Sln 而不是解决方案的名称）

Sln.DataAccess
+ Entities
  + Person.cs (contains the model definition of a Person)
  + IIdentifiedObject.cs (just an interface demanding a (Guid)Id property)
+ Repositories
  + IRepository.cs[1]
+ IUnitOfWork.cs[2]

Sln.DataAccess.Memory
+ PersonRepository.cs[3]
+ Context.cs[4]
+ GenericRepository.cs[5]
+ UnitOfWork.cs[6]

Sln.DataAccess.Sql (I suppose this could be Sln.DataAccess.EF but anyway...)
+ PersonRepository.cs
+ Context.cs
+ GenericRepository.cs
+ UnitOfWork.cs

Sln.Test
+ Various unit tests.

SQL 上下文/存储库/等...本质上都是相同的，只是它通过实体框架而不是内存列表访问数据库。

我要问的真正问题是我是否错过了整个 Repository/UnitOfWork 模式的标记，或者是否有任何建议任何人都可以提出我可以改进的地方。

这里是源文件。

• [1]https://gist.github.com/fddf625b1ee10bc0420a
• [2]https://gist.github.com/a020a016dd695309cb5c
• [3]https://gist.github.com/5f774e5f8dbcd41b1119
• [4]https://gist.github.com/9ab621962a5ea04403da
• [5]https://gist.github.com/a6d8f5f1b5fdcbbfaaf6
• [6]https://gist.github.com/7df0dca18489dd5555f8

Answer 1

没有建立存储库的标准方法。它旨在抽象 something，但对于不同的人来说，某些东西可能是不同的东西。有些人有通用查询方法，有些人只在 repo 本身有专门的查询。

我会首先考虑用例，然后设计存储库以适用于这些用例。设计一个地址簿应用程序，并考虑您的存储库是否可以方便地提供必要的功能。

Answer 2

好的，所以我实现了我想要的。

查看我在 Git 上创建的这个项目（它应该是打开的），它正是我想要的。

Sln.DataAccess 程序集对数据实际存储方式的引用绝对为零，其中没有类，只有定义访问对象方式和这些对象结构的接口。

实际的持久化方式（内存或数据库）完全隐藏在它们各自的程序集之外。

https://github.com/bmckenzie/projects

我想修复的一件事是我的内存中 Context 类中的 Set<>() 方法，请看这里：https://github.com/bmckenzie/projects/blob/development/Projects.DataAccess.Memory/Context.cs

如果有人有任何建议，我宁愿避免使用 if() {} 并使用某种字典？