我目前正在为一个数据库密集型项目构建存储库（性能测试已经进行并且需要缓存，因此我要问这个问题）
我现在设置它的方式是每个对象都单独缓存，如果我想对它们进行查询，我将查询传递给数据库并返回所需的 id。 （对于一些简单的查询，我已经缓存并管理了 id）
然后我用这些 id 访问缓存并将它们拉出，任何丢失的对象都捆绑到“where in”语句中并发送到数据库；在这一点上，我用丢失的 id 重新填充缓存。
他们自己的查询很可能是关于分页/排序数据的。
这是一个合适的策略吗？或者也许有更好的技术可用？
【问题讨论】：
这是一个合理的方法，我以前也走过这条路，最好用它来做简单的缓存。
但是，当您更新或写入数据库时，您会遇到一些有趣的问题，您应该小心处理这些情况。
例如，如果用户更新数据库中的记录，您的缓存数据将变得过时。在这种情况下，您需要同时更新内存缓存或清除缓存，以便在下一次提取查询时刷新它。
如果您例如用户更新客户的电子邮件地址，该地址位于单独的表中但通过外键关联，事情也会变得棘手。
除了数据库缓存之外，您还应该考虑输出缓存。例如，如果您有一个显示上个月销售数据的表格，这将非常有效。该表可以存储在另一个文件中，该文件包含在一堆想要显示该表的其他页面中。现在，如果您使用销售数据表缓存文件，当其他页面请求此文件时，缓存引擎可以直接从磁盘获取它，业务逻辑层甚至不会受到影响。这并不总是适用，但对自定义控件非常有用。
工作单元模式
了解Unit of Work 模式也很有帮助。
当您将数据拉入和拉出时 一个数据库，保存很重要 跟踪您所做的更改； 否则，该数据将不会被写入 回数据库。同样你 必须插入您创建的新对象 并移除您删除的所有对象。
您可以使用每个 更改为您的对象模型，但这 会导致很多非常小的 数据库调用，最终是 非常慢。此外，它需要你 有一个交易开放 全交互，即 如果您有业务，则不切实际 跨越多个事务 要求。情况更糟 如果您需要跟踪 你读过的东西，所以你可以避免 读取不一致。
一个工作单元跟踪 您在业务中所做的一切 可能影响交易 数据库。完成后，它会计算 列出所有需要做的事情 改变数据库作为结果 你的工作。
【讨论】：
如果您使用的是 SQLServer，则可以使用SqlCacheDependency，当数据库中的数据表发生更改时，您的缓存将自动重新填充。 这是 SqlCacheDependency 的链接
此链接包含类似的cache dependency solution。 （它是用于文件而不是数据库。您需要根据上面的 msdn 链接进行一些更改才能对数据库产生缓存依赖关系）
希望这会有所帮助:)
【讨论】：
我不建议自定义缓存策略。缓存很难。根据您选择的平台，您可能想要选择第三方缓存库/工具。
【讨论】：