Question

We have a MVC3 application that we have created many small actions and views to handle placing the data wherever we need to. For instance if it was a blog and we wanted to show comments, we have a comment action and view and we can place that wherever we want, a user profile view, and blog post view, etc.

The problem this has caused is each small view or action needs to make a call, usually to the same service, multiple times per a page load because of all the other small views we have in our application. So on a very large page containing these small views, we could have 80+ sql calls with 40% of them being duplicates and then the page slows down. Current solution is to cache some data, and pass some data around in the ViewBag if we can so if you want like a user’s profile, you check to see if its cache or the ViewBag if it isn’t ask for it.

That feels really really dirty for a design pattern and the viewbag approach seems awful since it has to be passed from the top down. We’ve added some data into HttpCurrent.Items to make it per a request (instead of caching since that data can change) but there has to be some clean solution that doesn’t feel wrong and is clean too?

EDIT

I’ve been asked to be more specific and while this is a internal business application I can’t give away to much of the specifics.

So to put this into a software analogy. Lets compare this to facebook. Imagine this MVC app had an action for each facebook post, then under that action it has another action for the like button and number of comments, then another action for showing the top comments to the user. The way our app is designed we would get the current users profile in each action (thus like 4 times at the minimum in the above situation) and then the child action would get the parent wall post to verify that you have permission to see it. Now you can consider caching the calls to each security check, wall post, etc, but I feel like caching is for things that will be needed over the lifetime of the app, not just little pieces here and there to correct a mistake in how your application is architected.

Answer 1

I see two potential places your code might be helped based on my understanding of your problem.

1. You have too many calls per page. In other words your division of work is too granular. You might be able to combine calls to your service by making objects that contain more information. If you have a comments object and an object that has aggregate data about comments, maybe combine them into one object/one call. Just a thought.

2. Caching more effectively. You said you’re already trying to cache the data, but want a possibly better way to do this. On a recent project I worked on I used an AOP framework to do caching on WCF calls. It worked out really well for development, but was ultimately too slow in a heavy traffic production website.

The code would come out like this for a WCF call (roughly):

[Caching(300)]
Comment GetComment(int commentId);

You’d just put a decorator on the WCF call with a time interval and the AOP would take care of the rest as far as caching. Granted we also used an external caching framework (AppFabric) to store the results of the WCF calls.

Aspect Oriented Framework (AOP): http://en.wikipedia.org/wiki/Aspect-oriented_programming
We used Unity for AOP: Enterprise Library Unity vs Other IoC Containers

I would strongly consider trying to cache the actual service calls though, so that you can call them to your hearts content.