Cache of Objects or Output in View: Which is better?

I have an ecommerce working in ASP.Net MVC. I'm using Caching to improve performance in my pages and it's working.

I'd link to know what offers better performance, for example, I can set OutputCache in my views and and use this cache for all page OR I could get my List of Products in controller, put it on cache (like the code below) and send it to View to render for the user?

private IEnumerable<Products> GetProductsCache(string key, ProductType type)
        {
            if (HttpContext.Cache[key] == null)
                HttpC开发者_开发问答ontext.Cache.Insert(key, ProductRepository.GetProducts(type), null, DateTime.Now.AddMinutes(10), Cache.NoSlidingExpiration);

            return (IEnumerable<Products>)HttpContext.Cache[key];
        }

public ActionResult Index()
        {
            var home = new HomeViewModel()
                           {
                               Products = GetProductsCache("ProductHomeCache", ProductType.Product)
                               Services = GetProductsCache("ServiceHomeCache", ProductType.Service)
                           };

            return View(home);
        }

Both work, but I'd like to know what is the preferred method to improve performance, or are there other, better ways to do this?

In your example, as Ivan pointed out, output caching would be slightly better performance wise. But only slightly.

From my experience the majority of performance gains come from data caching. Page processing is a relatively inexpensive operation however, database calls are not. So I always gzip and dump my data into the cache, inflating when I get it out of the cache. Hanselman has a nice example of a zipped cache if you are interested: http://www.hanselman.com/blog/CommentView.aspx?guid=aa479008-3d1e-45fc-b89f-e9c2ffc199c1

Also, output caching in mvc can be a little tricky. To cache a whole page is ok, just use the [OutputCache] attribute. However, if you only want to cache partials (which the majority of time you do), it gets a little more complex.

Caching is hopefully something MS will improve upon in mvc 3.

In a real ASP.NET MVC site you will hardly have the chance to use OutPutCache.

The problem is that there is no save way to use donut caching. This means you cache most of the page but have some parts that are user specific that you dont cache. This works in old school ASP.NET.

Phil Haack wrote about donut caching but it turned out to be not feasible in MVC2 http://haacked.com/archive/2008/11/05/donut-caching-in-asp.net-mvc.aspx

Often I started using OutputCaching not thinking about this little user specific detail everybody forgott.

You might think: I can work around it by doing some Javascript stuff that loads dynamic data...bad idea for a public facing website. There are non javascript clients and there is the google bot.

First I was frightened that this might bring our high traffic site down: But it works very well by caching the results of calls into the datalayer.

OutputCache will give better results. But it is not always possible to be used - for example if you have many dynamic ( user specific ) controls.

Caching the result is also a choice when the result set is used in many views. Your current implementation is not cache safe - i.e. if two or more threads get simultaneously in the if, which one will win when saving the result? Protect your cache with ReaderWriterLockSlim if you chose this way.

Also be careful with choosing cache time! I would suggest you build your application with sense of ability to cache, but do not cache unless totally sure something will take lots of time to execute ( may be your method needs improving? ). After your project is ready, profile it, and put cache where only needed!

But I suggest you investigate first - i.e. which one works better for you in given situation. Don't overuse one over the other, and don't overuse both!