VahidN
commented
7 years ago - It depends on the number of reads. If its too much (per user) and also you don't care about the amount of memory consumption (if you are using an in-memory cache), fine, use it. Otherwise the program will consume a lot of memory (caching different data for different users) which won't be used regularly. For instance if you want to cache the user's photo path, it's better to use user claims (stored in cookies) for that which are specific to each user. But if you are retrieving site's logo path from the database (or other site settings), it's better to cache it using the EFSecondLevelCache.Core. So one common use case for the second level cache is to cache static or very infrequently changing reference data. For example, a list of states/provinces and their attributes.
- Second level cache is not like Session variables and it's not limited to each user. It's a generally available data. make sure your private queries have
.where(x=>x.... && x.UserId == id), otherwise you can leak private info. - the 2nd level cache is invalidated / updated per entity when an entity is updated/deleted via EF. It is not invalidated if the database is updated in a different way.
lock[bot]
The readme recommends only caching public data, It would be good to provide the rationale for this, especially since caching commonly displayed per-user data can sometimes provide a nice performance improvement.