Data cache vs session object in ASP.Net

Question

Should dynamic business objects for a site be stored in the users session or use ASP.Net caching (objects such as orders, profile information etc)?

I have worked with sites that used sessions to store business objects, but I was wondering...What are the advantages or disadvantages of caching?

Answer 1

If the objects are shareable between user sessions, then use the cache. If the objects are unique to each session -- perhaps because they are governed by permissions -- then store it in the session. The in-process session itself is stored in the cache so the deciding factor really should be the scope of the data.

Answer 2

The ASP.NET system cache is global to the application where as the session is unique to the current user. If you chose to use the global cache to store objects you would need to create an object identification strategy so you could get the correct objects for your per user basis.

If you are looking to enhance performance you would be better off replacing the ASP.NET session state with a distributed memory cache such as Microsoft's velocity. Microsoft has posted articles on how to replace session usage to target Velocity. You could also use Memcache or other similar products in a related fashion.

Answer 3

Session objects are suitable for user-only-data, on the other hand, Cache objects are more suitable for data shared for the application.
The key to save in one or the other is to determine if what are you trying to store will be user-only data or it needs to be shared in all the application.

Session => A webpage with a step by step interface (an online test for example).
Cache => The info displayed in some kind of weather widget (like the one that google has in its igoogle.com page).
Hope this helps.

Answer 4

Caching is just that -- caching. You can never rely on entries being there, so no assumptions must be made in that respect: be prepared to go straight to the DB (or wherever else) to refetch data.

Session, on the other hand, is more suited towards storing objects, though personally I try to avoid session store in favour of a DB. I usually do that by abstracting away the store behind an opaque ISessionStoreService interface:

interface ISessionStore
{
    T GetEntry<T>(string key);
    void SaveEntry<T>(string key, T entry);
}

and then "dependency-injecting" appropriate implementation, be it InmemorySessionStore, DbSessionStore or whatever.