CODEWITHSUNDEEP
c#asp.net-mvcrazorumbraco
Alex
Alex

Reputation: 7919

Is it expensive to use multiple @Html.Action()s per page?

I am using Umbraco as a CMS in conjunction with Razor. A limitation of this approach is that my page templates are bound to an Umbraco-specific object that doesn't have all of the properties I need. So far, to get around this I have made multiple calls to @Html.Action() in order to display partial views that are constructed by my controllers.

Is this an expensive way to achieve what I want, and are there other ways of getting around the limitation of being bound to a viewmodel that you do not control?

Upvotes: 2

Views: 167

Answers (1)

Digbyswift
Digbyswift

Reputation: 10410

Of course the answer to this question is "it depends".

Each @Html.Action() makes a independent request to an action on a Controller. Obviously any calls to @Html.Action() produce more of an overhead than none at all.

In addition to this, in Umbraco assuming you are calling actions on SurfaceController classes, there is the additional layer that Umbraco introduces instantiating the controller with contexts and wiring up the actions.

However, all that said using @Html.Action() allows you to split your view models and serve up functionality independent of your page model. This is the pay off and I think it is enough of an advantage. The important thing here is to ensure that you use this technique enough to make the code base manageable whilst still making the requests efficient. For example, don't use it display content that can be accessed directly via the page's model. For this you could just use a partial.

You should always review your ChildAction code to ensure that caching is used wherever possible and appropriate to reduce the amount of processing per call. For example, I always use a ChildAction to generate my main navigation, but since the nav never changes I cache the model returned so the call to the action is as quick as it could be.

Finally if you controllers have dependencies like EF database contexts etc. make use of IoC containers like Autofac to ensure that dependencies are spooled up once per instance and then shared. This ensures that any resources that controller (and therefore the actions) use are duplicated.

Upvotes: 1

Related Questions