There is plenty of documentation on the asp .net cache object so I don’t want to go into too much detail. In summary:

1. Allows you store objects in memory
   
2. When the web application is recycled the entire cache is lost
   
3. When items are added they can have an expiration policy based on time (a sliding window if needed) and/or dependencies on other objects e.g. if a file changes on disk, then the cache item becomes invalid
   
4. Items are removed from cache when they expire or if memory pressures on the machine mean that items must be purged from the cache. ASP .Net will then remove items based on their priority, even if they haven’t expired.
   
5. A web part is really just an ASP .Net server control and hence there is no reason why you cannot implement caching in the control like you would any other server control. Either caching objects used by the control or the html rendered by the control. There is nothing web part specific in this scenario. One advantage of using this model is that multiple instances of your control can share the same cache, for example on 200 web part pages you have the same web part with the same data irrespective of the user viewing it. Here you would like to cache the data only once, not 200 times or even more if you do it on a per user basis. Also, you are using the ASP .Net cache which is tried, tested and …and works!

If you choose to use the built in caching functionality of the web part framework you have the option of storing the cache in memory or in SQL Server. This is designed to be configurable, i.e. changing an option in web.config will change the store for **ALL** web parts for that web application. In some way you could say that this is something that an administrator can change at any stage, however the reality is that this is not the case.

[Read More]