如何使用Repository模式连接点？

Question

我在这个模式上搜索得太多了，我觉得我很迷惑自己，所以你的意见将不胜感激。

如果我有我的小应用程序的数据库，这将它描绘：

• 公司
  • 名称
  • 地址
  • TemplateFilePath
• 部
  • 名称
  • 地址
  • 报告编号
• 事故
  • 报告编号
  • 位置
  • DriverLastNames
  • 日期

基本上，我已经编写了一些代码，将我的模型对象序列化并反序列化为JSON，但代码很混乱且紧密耦合。我想基本上抽象一下，所以当我决定稍后使用数据库时，随着应用程序的增长，切换会相对容易。

现在，如果我要制作存储库（我认为它不会是一个存储库），那么方法签名会是什么样子？我会使用任何接口吗？这里是我开始这样做：

IRepository<T>

• Add(T Entity)
• Delete(T Entity)
• Update(T Entity)

ICustomerRepository : IRepository<Customer>

• GetAllCustomers()
• GetCustomerByName(string name)

IDepartmentRepository : IRepository<Department>

• GetAllDepartments()
• GetDepartmentByName(string name)

然后我就开始想，我不会被写DRY代码...客户和部门库基本上是做同样的事情，唯一的区别是方法名称和实际的数据库表或文件的信息被存储在。我在做对吧？

从我一直在阅读的内容来看，存储库只是实际存储的包装。就像我正在使用SQLite一样，我将在存储库中建立连接，而我的常规代码只会处理Customer和Department类，不了解SQL连接或de/serializing，以及只知道存储库。

Answer 1

设计明智，它看起来不错。在基本接口中保留非常通用的方法（例如，Insert/Delete/Update/GetById）以及实体特定接口中的专用函数是一种相当标准的方法。我明白最重要的部分是客户不需要知道除界面之外的任何东西，所以只要让界面尽可能清晰即可。当设置接口时，您可以选择干净完全独立于客户端的存储库实现。

Answer 2

的一点想法：

• Update()一般不会在存储库级别进行处理，因为你通常最需要一次保存实体的整个图形的变化，不只是一个。处理这种情况的一种常见方式是通过应用服务/用例级别的工作单元，这可能反过来利用ORM的变更跟踪器。

• 是的，如果您希望将不同的Repository实现注入其消费者，则需要接口，例如在测试中模拟Repositories。

• 而不是试图弄清楚接口的层次结构，我喜欢做的是采取需求驱动的方法。换句话说，当你发现你需要它们的时候创建Repository接口 - 当你意识到你需要与一个模拟Repository进行交谈时，它可能在单元测试中，可能是在编写生产代码时。客户端代码使用存储库的方式将影响您的接口，并且您将确保每个接口都真的存在。