Repository navigation
Revisit MemoryCache design #36556
Description
The current design of MemoryCache is awkward due to the IMemoryCache interface where ICacheEntry CreateEntry(object key) exists instead of a more intuitive Set(object key, object value). The expected usage pattern is to call Dispose() on the ICacheEntry to "commit" the entry to the cache but this is unintuitive as well. This proved to be an issue when attempting to implement a strategy based eviction trigger and strategy in aspnet/Caching#280. We should revisit this design and see if there are possible improvements.
Activity
muratg commentedon Jan 3, 2018
Putting this tentatively in 2.2.0.
muratg commentedon Aug 31, 2018
This is not currently in scope. We'll revisit in a future release.
cc @DamianEdwards
analogrelay commentedon May 15, 2020
The fact that you have to
CreateEntryand thenDisposethe returned value to add it to the cache has been very non-intuitive to users. It'd be nice to take a look at a better API here.maryamariyan commentedon Sep 30, 2020
@JunTaoLuo is this still needed? (Referring to aspnet/Caching#280 (comment))
Also since we have a Set extension method here:
runtime/src/libraries/Microsoft.Extensions.Caching.Abstractions/src/MemoryCacheExtensions.cs
Lines 44 to 50 in 855e296
JunTaoLuo commentedon Oct 13, 2020
The point of the issue is that the pattern of using
CreateEntryand then callingDisposeto add the entry to the cache is unintuitive. We do have more convenient helpers likeSetso that most people don't need to directly use that pattern when interacting with a cache. However, the underlying issue of the unintuitive API remains. That said, given that there hasn't been much traffic on this issue, maybe it's not a problem for most users, in which case we can either backlog or close this issue.adamsitnik commentedon Nov 15, 2023
The current design is far from perfect. I agree that we need a re-design. Pplease follow #48567 which includes your proposal and some other good ideas. Thank you!