Revisit MemoryCache design

[JunTaoLuo]

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.

cc @davidfowl @DamianEdwards

[muratg]

Putting this tentatively in 2.2.0.

[muratg]

This is not currently in scope. We'll revisit in a future release.

cc @DamianEdwards

[analogrelay]

The fact that you have to CreateEntry and then Dispose the 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]

@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

	public static TItem Set<TItem>(this IMemoryCache cache, object key, TItem value)
	{
	using ICacheEntry entry = cache.CreateEntry(key);
	entry.Value = value;
	return value;
	}

[JunTaoLuo]

The point of the issue is that the pattern of using CreateEntry and then calling Dispose to add the entry to the cache is unintuitive. We do have more convenient helpers like Set so 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.