*ForCaching classes

Could you please tell me why we use *ForCaching classes for caching like StoreForCaching instead of classes itselfs like Store?

It's a workaround because EF doesn't support 2-level caching (between HTTP requests)

Dear Andrey;

Why we dont use entity classes itselfs? In nope there are 3 different caching services. Per request, memcache and distributed. As i see these caching services do their work independently from any data access technologies. Does it affect these caching services if we use entity classes instead of *ForCaching classes? I don’t think so. Please explain it detailed because i already knew we use it for 2nd level caching. I just don’t know why not entity classes itselfs. Why we need new classes?

Regards.

iyilm4z wrote:

Hi iyilm4z,

You could not cache entity classes since using the EF these classes become proxies (not the actual classes).
These proxy objects contain db context etc. which are disposed. For example if you cache an entity and later on (another request) you try to access any navigation property of that entity you will end up with an error.

Another reason (for not caching entities) is if you use RedisCache which doesn't use binary serialization and it will not be able to recreate these proxy classes when you need them from the cache.

Hope this helps!

Thanks,
Boyko

Hi Boyko,
Thank you very much for your answer which makes sense!
According to your answer, if i use Dapper or ado.net with per request caching(http) or in-memory cache(not redis), i could be able to use entity classes itselfs inserted of *ForCache classes, am i right?

iyilm4z wrote:

HI iyilm4z,

Yes, I think you should be able to do.

Why don't you want to use *ForCache classes? Have you noticed any issues with them?

Thanks,
Boyko

Dear Boyko,

Have you noticed any issues with them? - No i haven't.
Why don't you want to use *ForCache classes? - I use but i did't know why we exactly use them.

You made it all clear for me.

ogromnoe spasibo!)