What is the cost associated with html.action calls within html.partial calls in MVC3?

So I'm creating a webpage using MVC3 that is supposed to be highly customizable. For example, take the IMDB page of a TV show. It has multiple components (henceforth known as widgets): the header information, cast list, episode list, random trivia, quote list, forum preview, etc.

Let's say I was creating an IMDB clone, and depending on the type of page (movie, TV show, actor), you show d开发者_如何学Pythonifferent widgets. And the user can also change preferences to add or remove certain widgets from each type of page.

In my design, I have it so that the controller for the main view is passing a collection of "widget view models" that contains the information needed to get the information needed for each individual widget. So it will provide the ID (to get the information from the database), the controller and action.

Inside the main view, it iterates through this list of widget view models and calls an html.partial for a generic widget container partial view that contains the common HTML and JavaScript/jQuery for each widget and passes an individual widget view model to that partial view.

Inside that partial view, in the content div of the generic widget container, it calls another html.action to get the specific widget partial view by making a call to the specific controller action that gets the information by the id field of the widget view model.

Cliff notes: List of metadata objects -> main view. Each metadata object -> common partial view. Partial view -> another partial view to get data using the metadata.

So now that you've read all of that, I have two questions:

1. What is the cost associated with having multiple html.partial calls within a main view, with each partial view calling an html.action?

2. Is this a good, logical design?

Interesting question - I did a couple of experiments because I wanted to know the answer myself.

1) The cost is controller object creation. Each time you call Html.Action() a new instance of the controller object is created. This is true even if you call multiple actions on the same controller in the course of the same view (I tried this). This is good behavior, since it assures every action has a clean slate.

@Html.Partial shouldn't be a burden at all - the compiler should optimize things.

The downside is that if your controllers are doing heavy lifting with external services (like a database) you could end up with quite a few connections open at a time while serving a single request (at least one for your parent page and one for the view, since the controller doesn't get disposed of until the view has rendered - for your sub views this should be at the end of Html.Action). So you'll need to be aware of this - if your actions create expensive resources this could add up.

2) As a design, notwithstanding the above, it doesn't seem that bad to me. You get some nice separation of concerns, none of your individual code gets overcomplicated, and you generally always know where your code is.

The decision you have to make is performance optimization versus development optimization, and that depends on the weight of your controller actions.