Triggor

Follow My Heart
  博客园  :: 首页  :: 新随笔  :: 订阅 订阅  :: 管理

RenderPartial vs RenderAction

Posted on 2011-07-06 09:30  triggor  阅读(291)  评论(0编辑  收藏  举报

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  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,