3

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

我开始阅读有关存储库和工作单元模式的内容，这让我很感兴趣。我以前从未使用过 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 Context/Repository/etc...本质上是相同的，只是它通过实体框架而不是内存列表访问数据库。

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

这里是源文件。

4

2 回答 2

1

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

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

于 2012-04-25T18:46:31.683 回答
0

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

在 Git 上查看我创建的这个项目（它应该是打开的），它准确地展示了我想要的。

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

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

https://github.com/bmckenzie/projects

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

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

于 2012-04-26T18:43:13.503 回答