MichaCo
AspNet Core WebApp example
Issue to track progress / discussion around creating an example website using ASP.NET Core.
- DI example code
- Configuration example code
- Usage (with ValuesController only?)
- What would be a good/still simple usage example?
I'm not sure if this is possible but I would love so see the following example: A MVC web app using .Net Core 1.1 ready to deploy to Azure. Only the "Infrastructure" layer and the DI layer (web app) should know about CacheManager. All other layers uses the IDistributedCache interface.
The cache should be configured to have a primary local cache (using Memory Cache) and a secondary distributed cache (Redis).
The example should use the "cache aside" pattern.
This setup would have the following benefits:
- Best practices in architecture follwing the SOLID priciple
- Lowest cost for azure
- Best performance
All other layers uses the IDistributedCache interface
Why would you do that? IDistributedCache limits the functionality by a lot
The example should use the "cache aside" pattern
Not sure if that's necessary. There is currently no other store in the sample. Not sure yet if I'm going to add a sql store or something like that, depends on how complex the sample will get... ;)
Why would you do that? IDistributedCache limits the functionality by a lot
I want to keep the actual implimentation of the caching away from the other projects in the solution. The developers should only have access to small interface so I don't want to install a full nuget package in all my projects.
I could create my own ICacheProvider and then just impliment the methods I want to expose but that doesn't feel right. :(
For IDistributedCache you have to add Caching.Abstractions everywhere. For ICacheManager you have to add CacheManager.Core everywhere. What's the difference? ^^
In addition, you loose a lot of functionality of ICacheManager if you don't use that interface, like update, events, etc...
So, yeah, if you want to do that, that's up to you but for a sample for CacheManager that's not an option at all.
Yeah, I know. MS did this to split the actual implementation from the interfaces. That way, anyone can implement caching the way they want it and it's easy to DI.
How about this?
If there were a CacheManager.Abstractions Nuget library, containing the ICacheManager interface, and that interface inherits the IDistributedCache interface, that would make developers be able do the following:
- Exchange there current IDistributedCache implementation for CacheManager without changing any of there code (except DI).
- Install a small Nuget package and replace there IDistributedCache with ICacheManager and easily Migrate to Cache Manager to gains access to more functionality.
Don't get me wrong. I love Cache Manager and you have done a awesome job with this library. I'm just trying to find a way to implement caching with minimal dependencies and stopping my developers from access functionality they should should not use. Core exposes a bit to much in my opinion.
I cannot inherit from IDistributedCache, I would have to add a dependency to the Microsoft stuff to my Core package which is used everywhere... CacheManager is not always used in that domain. So, no, that's not an option.
The only thing I can add (and was planning to) in the future, is another CacheManager package which implements IDistributedCache with CacheManager. But again, there is no need to use IDistributedCache at all if you have ICacheManager.
Also, IDistributedCache is pretty low level and harder to use. You have to deal with byte[] only for set/get for example..., Meaning, you'd have to de-/serialize before any operation, which makes the interface pretty much useless from an easy-to-use integration standpoint.
To make your developers' lives easier, you should not use it at all I'd say... Everyone would have to implement serialization and such everywhere which would be really bad...
Build your own abstraction if you want to enforce limited functionality and plug that on top of ICacheManager or IDistributedCache. That's perfectly fine. If you enforce that only your custom interfaces get injected to any business logic, no-one will even notice that there might be different things underneath. Question is still why you'd do that in the first place, but that's probably off-topic.
Dependencies are not really that different/hard to maintain. If you want to use caching, you don't have to use Microsoft.Extensions.Caching at all, I mean, they use it internally for MVC somewhere, but that's it.
@Eneuman don't get me wrong, I like some your ideas and will work more on the samples if I find some time. I also hope my last answer made some sense to you ;)
It did :) I have decided to go with ICacheManager. After giving it a second look it makes life easier then having to deal with the byte/serializing stuff, and creating a custom interface to hide some of the functionality didn't add enough business value. Thanks for your thorough answers!
Wow this issue is old! Nevertheless, let me add my thoughs.
The only thing I can add (and was planning to) in the future, is another CacheManager package which implements IDistributedCache with CacheManager.
This would be ideal, in my opinion, simply because it can be easily integrated with other third party libraries that uses IDistributedCache internally, without any hassle.
For instance, IdentityServer and IdentityModel, internally uses IDistributedCache to cache introspection tokens. By simply adding an implementation to the services collection, it will use it without further configuration.
But again, there is no need to use IDistributedCache at all if you have ICacheManager.
If I choose to use caching in my domain classes, I agree, ICacheManager is the way to go.
Would be really nice to have the extension for IDistributedCache though, but maybe this is a topic for another issue.
@SuricateCan wow yeah this issue is pretty old. I never had the time or motivation to build anything on top of IDistributedCache.
To be honest, the interface is so trivial that it should be relatively easy to just role your own in a couple of lines of code and use CacheManager as backing store with a 2-layered cache anyways ^^