We have multiple lookup tables in a SQL Server database. Tables are used in application dropdown menus.
Instead of continually reading database lookup tables, team wants to apply
Redis Cache (to reduce database load, and increase in-memory performance). However, we learned that Entity Framework Core
DbContext already has caching.
So in this case, would there be any value in caching looking tables, if after a certain amount of reads, the
DbContext does this already?
Would adding more caching code for
DbContext help? Or would it be an unnecessary layer?
As with Microsoft is EF Core 2.0, EF Core supports only First-Level Cache, that is, when an entity is materialized as the result of executing a query, it is stored in an in-memory cache associated with the Entity Framework Context ( a.k.a System.Data.Entity.DbContext class )
EF Coreâ€™s first level caching mechanism provides some performance boost, however, consider a scenario where the entityâ€™s record changes in the database level and we are still working off of locally cached copies of entities from the Entity Framework context. so this leads to a situation where we will get an incorrect result set.
So a workaround for this problem is to detach those entities from the context, which effectively means removing it from first-level cache, also termed as eviction of the cached item. Once detachment is done, entities may be fetched once again, which would ensure that fresh data is read from the database.
So, we see that EF Coreâ€™s out of the box (OOB) first-level caching mechanism is far from perfect. It leads to clunky code which is prone to errors and there is fairly a good chance of the code base becoming convoluted and unmaintainable in the long run. A few of the other drawbacks of EF Core OOB first-level caching mechanism are:
So as you can see given the need of scaling for Distributed applications , it is highly recommended to go for usage of Caching Providers.