MichaCo
commented
6 years ago @ilyazolotarov The solution to have ONE non-generic instance of CacheManager instead of many different generic ones already exists today, just use T=object.
I agree that it might be a good addition to optionally share the in-memory cache across multiple instances (same configuration might be hard to handle. idk). I'll keep that in mind.
Re: Problem with MS.Extensions.Caching.Memory; what exactly is the issue with that one? Did you see they removed the garbage GC implementation in 2.0 because it didn't work? ;)
ilyazolotarov
The problem: Assume we have shared configuration instance with simple in-process cache handle. Then we register ICacheManager in our DI container as open generic service with singleton lifetime, so proper closed generic implementations will be constructed on demand. All this implementations use our shared configuration. What to do if we want to clear all cache for all this managers at once? Since every implementation of manager has its own internal cachehandle we should be able to get somehow all this managers and call "Clear" on every such instance.
Additional thoughts: In addition to this particular problem there are some other potential problems associated with the current implementation. For example MemoryCache from Microsoft.Extensions.Caching.Memory is designed to have only one instance per application because of how it needs to respond to memory pressure via GC notifications. In addition, current implementation brings inconsistency when it comes to distributed cache handles such as redis.
Solution: The solution is to have non-generic implementation for cache handle and have only one handle instance per configuration instance. So generic cache manager would be responsible to only cast untyped object result to concrete type. Or even non-generic implementation of cache manager with generic (or with explicit Type parameter) CRUD methods.