At first glance, RenderAction and RenderPartial both do a very similar thing – they load ‘some other content’ into the view being rendered at the place they are called. Personally, I think they should be used for different scenarios so these are my thoughts on where each one should be used and why.
First though, a quick recap on what they do:
- RenderPartial renders a control with some model passed to it.
- RenderAction (or RenderSubAction which addresses some issues) calls a controller action and then renders whatever view that returns with whatever model that controller action passes through it.
Hmmn, they sound pretty similar don’t they! The thing to note though is that the model passed to RenderPartial is either the current model being rendered by the calling view or a subset of it. Anything that a RenderPartial view being called is going to need has to be passed into the Model of the calling view. The view rendered using RenderAction on the other hand could contain a completely different model with no need for this to be passed in to our parent view.
Because of this, I think RenderPartial is most appropriate when what it is going to output could be considered part of the calling view but separating it out into a user control makes sense to allow re-use and avoid repeating the same rendering code in multiple views. For example, if you are rendering a person name in lots of places then instead of repeating within each view the code to output it:
<a href="<%= Url.Action("Display", "Person", new { id = Model.Person.Id}) %>">
<%= Model.Person.Salutation %> <%= Model.Person.Forename %> <%= Model.Person.Surname %>
</a>
Instead, you move this to a separate user control such as ‘PersonName.ascx’ which expects a Person as the model:
<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<Person>" %>
<a href="<%= Url.Action("Display", "Person", new { id = Model.Id}) %>">
<%= Model.Salutation %> <%= Model.Forename %> <%= Model.Surname %>
</a>
Now, any place a view wants to output a persons name then you can instead call a PartialView and pass in the appropriate model:
<%= Html.RenderPartial("PersonName", Model.Person); %>
Why would you want to do this? Well, it helps consistency and avoids repetition which makes it easy if, for example, you decide that name should not longer be in the format “Mr John Smith” but instead “Smith, John (Mr)” and you want to throw in a little jQuery magic to display a profile popup whenever anyone hovers the mouse over the name. This is a simple example but hopefully it demonstrates some benefits of using it compared to repeating the code in each view – with larger chunks of output the benefits of using RenderPartial would be even more apparent
So that is where and how I think RenderPartial should be used. How about RenderAction?
Well, I think this has it’s place when the thing that needs to be rendered isn’t the responsibility of the calling view or controller.
For example, I may have a PersonController responsible for CRUD operations on the Person class including a Display action and view but I do not want either of these to have any responsibility for anything to do with the display of Projects that the person is working on. If I want to display a list of assigned projects within the Person Display view then I would use RenderAction to add it but the responsibility and knowledge of how to do this resides with the ProjectController and it’s views. This would be called as follows:
<% Html.RenderAction("List", "Project", new {personId = Model.Person.Id}); %>
(incidentally … note that, unlike many of the other extension methods, RenderAction doesn’t return a string so there is no ‘=’ at the beginning and a ‘;’ at the end)
Now, how the Project List is retrieved and rendered is completely the concern of the ProjectController class as it should be and the output can contain whatever it needs to display the list, provide actions to edit project entries and so on.
Another benefit of this approach is if you create different skinned versions of an app. By keeping things modular it is much easier to decide to include something in the view for one skin but not another. So, the skin (set of views) for a full desktop browser may call RenderAction to include the list in the same page whereas the skin for a mobile device friendly interface (think iPhone) would perhaps just include a link instead – both are handled by changing the view instead of changing the controllers which could otherwise be the case.