存储库模式 - 缓存

Ben*_*eni 30 caching repository-pattern

我不确定在我的存储库模式中应该在哪里实现缓存.

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

GUI - > BusinessLogic(服务) - > DataAccess(存储库)

ssm*_*ith 52

最好不要将缓存逻辑直接放入存储库,因为这违反了单一责任原则(SRP)和关注点分离.SRP基本上声明您的类应该只有一个改变的理由.如果您将数据访问和缓存策略的问题混淆在同一个类中,那么如果其中任何一个需要更改,您将需要触及该类.您可能还会发现您违反了DRY原则,因为很容易将缓存逻辑分散在许多不同的存储库方法中,如果其中任何一个需要更改,您最终必须更改许多方法.

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

如果您更喜欢视频,我还会在Pluralsight上的代理设计模式中描述模式,这里:

  • @ssmith 我认为你对开放/封闭原则和 SRP 的理解相当狭窄。编辑现有类并不是邪恶的,事实上,它应该是为了重构、提高性能、更新对新 API 的内部依赖关系等。类应该关闭以进行更改其公开的 API 的修改,并为涵盖以下内容的 API 扩展打开:按需需求但仍在原始 API 的范围内。这与SRP的想法是一样的,只要你公开的API不改变,你就可以而且应该出于上述原因编辑你的代码,就像在本例中一样,以提高性能。 (2认同)

Kal*_*exx 25

我会在存储库/数据访问层中处理它.原因是因为它不取决于从何处获取数据的业务层,即存储库的工作.然后,存储库将根据数据访问逻辑的情况决定从何处获取数据,缓存(如果它不是太旧)或从实时数据源.

这是一个数据访问问题,而不是业务逻辑问题.