存储库模式 - 缓存答案

【问题标题】：Repository Pattern - Caching存储库模式 - 缓存
【发布时间】：2020-03-16 18:51:58
【问题描述】：

我不确定应该在我的存储库模式中的何处实现缓存。

我应该在服务逻辑还是在存储库中实现它？

GUI -> BusinessLogic（服务）-> DataAccess（存储库）

【问题讨论】：

【解决方案1】：

最好不要将缓存逻辑直接放入存储库，因为这违反了单一职责原则 (SRP) 和关注点分离。 SRP 本质上是说你的类应该只有一个改变的理由。如果您将数据访问和缓存策略的关注点放在同一个类中，那么如果其中任何一个需要更改，您就需要接触该类。您可能还会发现您违反了 DRY 原则，因为很容易将缓存逻辑分布在许多不同的存储库方法中，如果其中任何一个需要更改，您最终不得不更改许多方法。

更好的方法是使用代理或策略模式在单独的类型中应用缓存逻辑，例如 CachedRepository，然后在缓存为空时根据需要使用实际的以 db 为中心的存储库。我已经写了两篇文章来演示如何使用 .NET/C# 来实现这一点，您可以在我的博客上找到这些文章：

如果您更喜欢视频，我还会在 Pluralsight 上的代理设计模式中描述该模式，此处：

https://app.pluralsight.com/library/courses/patterns-library/table-of-contents

【讨论】：

我同意你的做法。遗留业务逻辑类继续使用非缓存存储库，新的业务逻辑服务可以使用新的。您对现有逻辑的影响较小
SRP 适用于一个类。您可以在存储库模式中实现缓存，而无需在 1 个单个类中完成所有操作
@Hilikus 是的，如果您遵循此处描述的方法。这就是重点。 :) 如果您将缓存责任添加到已经负责持久性的存储库类中，那么这不仅仅是一项责任。
@ssmith 我认为您对开放/封闭原则和 SRP 的理解非常狭窄。编辑现有的类并不是邪恶的，事实上它应该是为了重构、提高性能、更新对新 API 的内部依赖关系等目的而进行的。一个类应该关闭以进行更改其公开 API 的修改，并打开用于覆盖的 API 扩展按需需求，但仍在原始 API 的范围内。这与 SRP 的想法相同，只要您公开的 API 没有更改，您就可以并且应该出于上述原因编辑您的代码，就像在本例中一样，以提高性能。
@ssmith 关于 CachedRepository。您通常有 2 个选项：1) 使用公开 API 的 Cache 对象来检索/保存到本地存储。 2）在CachedRepository里面写缓存逻辑。现在，如果您选择选项 2 并公开缓存 API，那就不好了，因为这样的 API 与 Repository 的逻辑域不一致。如果您选择选项 2 而不公开缓存 API 或选项 1，则创建另一个类是没有意义的，只需编辑原始类以使用策略模式。代理模式在这里也很糟糕，因为用户在使用它时不应该考虑任何副作用。

【解决方案2】：

我会在存储库/数据访问层处理它。原因在于，从何处获取数据不取决于业务层，这是存储库的工作。然后，存储库将根据数据访问逻辑的情况决定从哪里获取数据、缓存（如果不是太旧）或从实时数据源获取数据。

这是一个数据访问问题，而不是业务逻辑问题。

【讨论】：

感谢您的回答！我认为实现延迟加载也更好。
恕我直言，这首先是一个性能问题，这就是我们通常进行缓存的原因，不是吗？并且缓存业务层效率更高，因为您避免每次都重新执行业务逻辑