Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
RenderPartial vs RenderAction

If you have been using the MVC framework I am sure you are aware that in many cases there are multiple ways to accomplish the same task.  One such case in point is how to render content for a View.  Now I am not talking about how to render an entire View, but rather how do I render partial Views (aka user controls).

Let me paint you this picture.  In your master page you have some CastsTags common content you want to render in every view and this content needs to hit the business layer to perform some sort of logic.  How do you generate this content (the end result is like what you see to the right)?  The HTML content to the right is generated in a User Control so it is completely isolated from my main view or master page.

There are at least 2 different ways you can include data into your View and both of them have their pros and cons, but I personally feel one stands out as the clear favorite.

Approach 1: Using Html.RenderPartial

One way to render a user control is to use the Html.RenderPartial helper.  This will accept the name of the user control to render and optionally the data that is needed to build the user control.  You can see a simple example below.

<% Html.RenderPartial( "SomeControl.ascx", ViewData.Model ); %>

This works well and can be very useful, but lets take a look at the pros/cons with this approach.

Pros:

  1. Simple to use, no need to create any controller actions

Cons:

  1. Your view now has intimate knowledge of not only which user control/partial is should render, but how to find it.
  2. Your view need to provide the data to another view and this in itself has two issues
    1. Your view has to be aware of how it should populate other entities, this should NOT be the views job as this is business related logic.
    2. Because you can provide data, you could be tempted to skip the controller layer (aka traffic cop) and simply make a direct call to into your service layer, or worse yet directly into the database

Approach 2: Using Html.RenderAction (in Microsoft.Web.Mvc)

Another way to render a user control is to follow the same process as you would to render your View.  Let the controller determine which view (aka partial or user control) to render.  You can accomplish this by using Html.RenderAction (which is part of Microsoft.Web.MVC assembly).  This will allow you to specify a controller action to call which will determine which view/partial/user control to render.  Take a look at the simple example below for how to use RenderAction.

<% Html.RenderAction<MyController>( x => x.ControllerAction() ); %>

I feel that this works well  and can be useful, but lets take a look at the pros/cons with this approach.

Pros:

  1. You let your controller action do what it does, perform organizational logic and can make requests into the business layer to perform business logic.
  2. Abstracts away which actual view/partial/usercontrol is going to be used in this location.  This is nice because it allows for simpler refactoring in the future.
  3. Abstracts away any business related logic into the controller.  This helps with keeping your business logic in the correct place
  4. Is strongly typed since it uses lambdas.

Cons:

  1. You have to create another controller action to handle the request.

As you can tell from my list of pros/cons I think that calling RenderAction is a far better option. 

Till next time,

[---- Visit DimeCasts.net ----]


Posted 11-24-2008 4:08 PM by Derik Whittaker

[Advertisement]

Comments

DotNetKicks.com wrote Learn how to chose between renderpartial and renderaction
on 11-24-2008 8:24 PM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Brad Wilson wrote re: RenderPartial vs RenderAction
on 11-24-2008 8:39 PM

Your con #1 for RenderPartial doesn't make sense, maybe because your example is wrong. You shouldn't be calling:

<% Html.RenderPartial("foo.ascx"); %>

Instead you should be calling:

<% Html.RenderPartial("foo"); %>

and let the view engine system figure out which view (and where it comes from).

Your con #2 for RenderPartial could've been more succinctly as: "I prefer MVP over MVC, so I like RenderAction over RenderPartial". :)

Derik Whittaker wrote re: RenderPartial vs RenderAction
on 11-24-2008 9:07 PM

@Brad

Yes i could have simply left off the .ascx, but either way by having your view know which other view part to render you are providing inherit knowledge in your view.

Not sure I follow what you mean by MVP vs MVC??

Brad Wilson wrote re: RenderPartial vs RenderAction
on 11-24-2008 9:58 PM

Derik,

There was actually an extensive discussion in the comments to one of my posts. Rather than repeat it here, I'll point you to where the discussion begins:

bradwilson.typepad.com/.../partial-renderi.html

Reflective Perspective - Chris Alcock » The Morning Brew #230 wrote Reflective Perspective - Chris Alcock &raquo; The Morning Brew #230
on 11-25-2008 3:39 AM

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #230

ASP.NET MVC Archived Buzz, Page 1 wrote ASP.NET MVC Archived Buzz, Page 1
on 11-25-2008 6:12 AM

Pingback from  ASP.NET MVC Archived Buzz, Page 1

Jitesh Patil wrote re: RenderPartial vs RenderAction
on 11-25-2008 9:31 AM

One of the biggest cons of RenderAction is the flow of data. In an MVC pattern, it is expected that the controller pass whatever data is required to the View and the View takes care of displaying data. With Render Action, the View is calling the controller which essentially reverses the data flow.

And #2 con for RenderPartial does make sense. Considering your scenario, of wanting to populate data for a master page, you have two options, one is to inherit your model from a master model and let the master page work with the master model. Or always pass the data in the ViewData for the master page.

Con #2.2 is also incorrect. It is not a con. It is simply a bad practice. What you say in Con #2.2 is exactly what Html.RenderAction does.

Derik Whittaker wrote re: RenderPartial vs RenderAction
on 11-25-2008 9:44 AM

@Jitesh,

Keep in mind that in my example I am talking about using this within a master page.  When using a master page there is NO controller that gets hit by default.  And i do NOT want each action to need to gather the various data needed for the master page.  To me this is just way too much noise in each controller.

Not sure i agree with you about your point on Con 2.2. By using the RenderAction method i am invoking the controller and this allows me to not have to put any type of business logic inside my view.

Dew Drop - November 25, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - November 25, 2008 | Alvin Ashcraft's Morning Dew
on 11-25-2008 11:42 AM

Pingback from  Dew Drop - November 25, 2008 | Alvin Ashcraft's Morning Dew

Steve wrote re: RenderPartial vs RenderAction
on 11-25-2008 9:08 PM

I load partial view data into div tags for later ajax calls to update those divs.  On initial load, I will many times use a partial view.

ie.  I am using NHibernate, loading a child collection, I don't want to call that object twice to show a view.

One call is made, the children passed to the partial view.

Then, on that view, if there is a 'in place edit', I can use ajax and update that partial view in the div with the new list of children.

I have no problem with partial views - they represent modular views into a many times complex page.

Web Development Community wrote re: RenderPartial vs RenderAction
on 11-29-2008 9:24 PM
Code Monkey Labs wrote Weekly Web Nuggets #40
on 12-01-2008 11:24 AM

Pick of the Week: Controlling Your Festive Lights with the .NET Micro Framework General New and Improved CLR 4 Thread Pool Engine : Daniel Moth writes about upcoming enhancements to the thread pool. xUnit.NET 1.1 Released : Brad Wilson announces a new

Code Monkey Labs wrote Weekly Web Nuggets #40
on 02-22-2009 10:35 PM

Pick of the Week: Controlling Your Festive Lights with the .NET Micro Framework General New and Improved CLR 4 Thread Pool Engine : Daniel Moth writes about upcoming enhancements to the thread pool. xUnit.NET 1.1 Released : Brad Wilson announces a new

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)