Best Practices and ASP.net Application Session Cache Templates

In asp.net, the main data stores are the application, the session, and the object cache. I used common sense hints / tips (for example, never put specific data to users in an application, never put unmanaged resources in a session, etc. Etc.), but to be honest, I never came across recommendations and examples of when to use what is on MSDN or from famous figures such as Haack and Gu that cover all three together (for example, Google first got to MSDN, talks about using the application as a global cache, if so, then what is the object cache for?

Also, what I find rarely discussed is a comparison in the script, for example, I know that this is a simple unnecessary boot memory usage using a session, but what happens if you used the object cache as an alternative to store the same data

Edit: this is the best information I've found so far: http://msdn.microsoft.com/en-us/library/ff647787.aspx

+4
source share
2 answers

Use a session to store user information, as the structure automatically associates each session store with a specific user.

Use the object cache for information that can be cached once and reused throughout the application or through a set of users. If you store user data in the object cache, you will have to come up with some kind of mechanism for linking cache entries. Not only will this require additional work on your behalf, but you can do it in such a way as to increase the likelihood that the vile user is somehow doing something like a merge of sessions.

I do not know when you will need to use the Application object. If I'm not mistaken, the Application object is more like a classic ASP than anything else.

Another form of caching that can be just as important is on-demand caching through the HttpContext.Items collection. This allows you to cache data for the lifetime of the request and is useful if you continue to request the same data during the same request (for example, from different user controls on the page). For more information about this approach, see HttpContext.Items - cache storage for each request .

+2
source

I would suggest creating a wrapper class, at least for the session, if they will be used throughout your code. Thus, you can introduce an instance of the class to do the real work and use the version for unit tests. I did this for a large project where the session was widely used, and it worked out pretty well.

You can combine this with a facade template - the wrapper will provide you with specific methods, rather than revealing a common interface. As an example, a session takes objects and returns objects; it is not strongly typed. A wrapper can have strongly typed methods of adding and receiving.

0
source

All Articles