Mediatr-使缓存无效/更新的正确位置在哪里 [英] Mediatr - Where is the right place to invalidate/update cache

问题描述

这个问题源于我问过另一个关于太多接口，QCRS和Mediatr库(请求/响应)的问题

This question stems from this other question I had asked about too many interfaces, QCRS and Mediatr library (request/response)

Mediatr:减少DI对象的数量

我创建了许多命令和查询，并且有许多行为，其中之一是Cache行为，对于每个查询，在针对db实际执行查询之前都会检查cache的值.到目前为止，这很好用，但是当我有一个UpdateSomethingCommand时，就会出现delima，一旦我更新了数据库中的基础对象，我想用成功保存到数据库中的内容刷新缓存.

I have created bunch of commands and queries and I have bunch of behaviors and one of them being is a Cache behaviour that for every query, cache is checked for the value before the query is actually executed against the db. So far this is working great, but the delima comes in when I have an UpdateSomethingCommand, once I update the underlying object in the db, I would like to refresh the cache with what was successfully saved to the db.

我的问题是具体何时真正更新缓存:

My question is specifically when to actually update the cache:

1. 在UpdateSomethingCommandHandler中(这可能会破坏SOLID主体)
2. 在UpdateSomethingCommandHanlder中调用另一个专门用于更新缓存的命令(不确定这是一个好的设计原理)
3. 介绍另一种专门用于更新缓存的行为(尚不确定如何解决此问题)
4. 有更好的解决方案吗?

推荐答案

对于使用MediatR并最终将缓存合并到中介程序管道中的项目，我们也有类似的需求，

We had a similar need on a project that uses MediatR and ended up incorporating caching into the mediator pipeline, including cache invalidation as you describe.

基本前提是，我们在管道中插入了两种不同的行为，一种用于缓存来自请求的响应，另一种用于使来自不同请求的缓存的请求响应无效.

The basic premise is that we have two different behaviors inserted into the pipeline, one for caching a response from a request, and one for invalidating a cached request response from a different request.

这两种行为之间存在一点相互作用，因为它们需要交换缓存密钥才能使正确的请求无效.

There is a little bit of interplay between the two behaviors in the fact that they need to exchange a cache key in order to invalidate the correct request.

我最近将其中一些工作拉到一个独立的库中，理论上可以使用MediatR将其按原样放置到任何项目中.就您而言，您可能只想看看我们在这里使用的技术，然后根据需要重新创建它们.

I've recently pulled some of this work into a stand-alone library that in theory can be dropped in as-is to any project using MediatR. In your case, you may just want to look at the techniques we've used here and recreate them as needed.

我不会再在这里和现在重复所有内容，而是将您指向项目页面，该页面的主页上入门"链接下有一些文档: https://github.com/Imprise/Imprise.MediatR.Extensions.Caching

Rather than repeat everything here and now, I'll point you at the project page where there is some documentation under the Getting Started link on the homepage: https://github.com/Imprise/Imprise.MediatR.Extensions.Caching

我认为，缓存失效使整个过程极其简单明了，但是在某些情况下，我们需要对失效发生的时间进行更好的控制.在这些情况下，我们采取的另一种方法是将ICache<TRequest, TResponse> cache注入到INotificationHandler s中，然后根据需要手动调用_cache.Remove(key);.然后，从您知道应该无效的任何请求中，仅引发由INotificationHandler处理的通知，例如_mediator.Publish(SomethingUpdated);

In my opinion, the cache invalidation makes the whole process extremely simple and straightforward, but there are cases where we needed finer control over when the invalidation occurs. In these cases the other approach we have taken is to inject an ICache<TRequest, TResponse> cache into INotificationHandlers and then call _cache.Remove(key); manually as needed. Then, from any requests you know should invalidate just raise a notification that is handled by the INotificationHandler e.g. _mediator.Publish(SomethingUpdated);

这篇关于Mediatr-使缓存无效/更新的正确位置在哪里的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！