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模式的标记，或者是否有任何建议可以提供给我可以改进的地方。

以下是源文件。

Answer 1

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

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

Answer 2

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

在我创建的Git上看到这个项目（它应该是开放的），它会准确地展示我想要的东西。

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

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

https://github.com/bmckenzie/projects

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

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

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

2 个答案: