Using RenderAction: Is Breaking the MVC Pattern Worth It?

the primary concern of the page is displaying a list of vehicles. however it also displays some statistics and a set of reminders. i labeled the stats and reminders as orthogonal because they are (in a sense) independent of the primary concern. finally, there is the ambient data of the currently logged in user. i call this data ambient because we expect it to be present on all the pages in the application.

it’s a common practice in mvc-style applications to map a single controller action to a view. that is, it is the responsibility of a single action to produce everything that is needed to render a particular web page.

the difficulty with this approach is that other pages often need to render the same orthogonal data. let’s examine the code for the action invoked by \vehicle\list.

public actionresult list()
{
    addcountrylisttoviewbag();

    var vehicles = using<getvehiclelistforuser>()
        .execute(currentuserid);

    var imminentreminders = using<getimminentremindersforuser>()
        .execute(currentuserid, datetime.utcnow);

    var statistics = using<getfleetsummarystatistics>()
        .execute(currentuserid);

    var model = new dashboardviewmodel
                    {
                        user = currentuser,
                        vehiclelistviewmodel = new vehiclelistviewmodel(vehicles),
                        imminentreminders = imminentreminders,
                        fleetsummarystatistics = statistics
                    };

    return view(model);
}

disregarding how you might feel about the using<t> method to invoke commands and other such details, i want you to focus on the fact that the controller is composing a model. we generate a number of smaller viewmodels and then compose them into an instance of dashboardviewmodel. the class dashboardviewmodel only exists to tie together the four, otherwise independent data.

personally, i prefer to avoid classes like dashboardviewmodel and simply rely on dynamic typing in the view. however, others feel strongly about having intellisense support in the view.

project silk had separate actions just to serve up json:

public jsonresult jsonlist()
    {
        var list = using<getvehiclelistforuser>()
            .execute(currentuserid)
            .select(x => tojsonvehicleviewmodel(x))
            .tolist();

        return json(list);
    }

reducing the code

while reevaluating this code for project liike , we decided to employ content negotiation . that is, we wanted a single endpoint, such as \vehicle\list, to return different representations of the data based upon a requested format. if the browser requested json, then \vehicle\list should return a list of the vehicles in json. if the browser requested markup, then the same endpoint should return html.

first, we needed to eliminate the differences between the json viewmodel and the html viewmodel. without going deep into details, this wasn’t hard to do. in fact, it revealed that we had some presentation logic in the view that should not have been there. the real problem was that i wanted the action to look more like this:

public actionresult list()
{
    var vehicles = using<getvehiclelistforuser>()
        .execute(currentuserid);

    return new contenttypeawareresult(vehicles);
}

only, the view still needed the additional data of statistics and reminders. how should the view get it?

we decided to use renderaction . renderaction allows a view to invoke another action and render the results into the current view.

we needed to break out the other concerns into their own actions. for the sake of example, we’ll assume they are both on the vehiclecontroller and named reminders and statistics. each of these action would be responsible for getting a focused set of data. then in the (imaginary) view for list we could invoke the actions like so:

// list.cshtml 
<ul>
@foreach (var vehicle in model)
{
    <li>@vehicle.name</li>
}
</ul>

<section role="reminders">
@{ html.renderaction( "reminders", "vehicle") }
</section>

<section role="statistics">
@{ html.renderaction( "statistics", "vehicle") }
</section>