如何组织和维护缓存键并刷新它们？
我们的系统在 Azure 上使用 AppFabric 缓存，并且我们有多种类型的应用程序和角色共享相同的缓存值。我正在寻找一些关于如何组织所有键的建议，并且还能够在条目被更改时使条目无效/刷新。
我尝试过使用一个带有一组创建键的方法的静态类的想法。例如：
string CreateUserByIdKey(int userId) - Returns "User_5"
string CreateWidgetsByCompanyKey(int companyId) - Returns "Widgets_Company_5"
这样我就有了一种半结构化的方式来跨不同的应用程序创建和使用密钥。但这感觉不太优雅且不易于维护。它还要求我创建特殊的刷新方法，以知道更新数据时需要使这些键中的哪些键失效。
有什么更好的方法来做到这一点？
Our system uses AppFabric Caching on Azure and we have multiple kinds of apps and roles that are sharing the same cached values. I'm looking for some recommendations on how to organize all the keys and also have the ability to invalidate/flush entries when they have been altered.
I've played around with the idea of having a static class with a set of methods that create the keys. For example:
string CreateUserByIdKey(int userId) - Returns "User_5"
string CreateWidgetsByCompanyKey(int companyId) - Returns "Widgets_Company_5"
This way I have a semi-structure way to create and use keys across different applications. But this doesn't feel very elegant and maintainable. It also requires me to create special flush methods that know which of these keys need to be invalidated when the data has been updated.
What is a better way to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们的方法是使用带有策略扩展的
CacheManager。 CacheManager 位于解决方案的核心部分，并且该核心通过所有角色进行引用。对于共享的内容，例如生成缓存键的策略，甚至端点名称，我们有一个
WellKnownComponents列表。这是一个 TT 生成的文件（好吧，文件），可以使用部分类进行扩展。在您的情况下，我要做的是将缓存键 id 生成函数添加到我众所周知的组件类中，然后通过应用程序进行引用，例如，
这大约是我们正在做的事情。是的，您仍然需要特殊的刷新方法来进行失效，但好处是您可以在重要且相关的地方将它们分开和组合（例如，您的一个组件，而不是围绕解决方案）。
Our approach is to use a
CacheManagerwith a strategy extension. The CacheManager is located in a Core part of the solution, and that core is referenced through all of the roles.For things that are shared, like strategies for generating cache keys, and even endpoint names, we have a list of
WellKnownComponents. This is a TT generated file (well, files), that can be extended with partial classes.What I would do in your case is add the cache key id generating function to my well known components class, and then reference through the application, e.g.
This is approximately how we are doing it. And yes, you still need special flush methods for invalidations, but the upside part is you can both separate and combine them where it's important and relevant (e.g. your one component, instead of around the solution).