Best Practice for Summary Footer (and the like) in MVC

Question

Simple question on best practice. Say I have:

public class Product
{
    public string Name { get; set; }
    public string Price { get; set; }
    public int CategoryID { get; set; }
    public bool IsAvailable { get; set; }
}

and i have a view using IEnumerable< Product> as the model, and i iterate through the Products on the page and want to show the total of the prices at the end of the list, should I use:

<%= Model.Sum(x=> x.Price) %>

or should I use some other method? This may extend to include more involved things like:

<%= Model.Where(x=> x.CategoryID == 5 && x.IsAvailable).Sum(x=> x.Price) %>

and even

<% foreach (Product p in Model.Where(x=> x.IsAvailable) {%>
-- insert html --
<% } %>

<% foreach (Product p in Model.Where(x=> !x.IsAvailable) {%>
-- insert html --
<% } %>

I guess this comes down to should I have that sort of code within my view, or should i be passing it to my view in ViewData? Or perhaps some other way?

Answer 1

If the logic you are using on the page is related to the display of data on the page, then I don't have a problem using logic that does calculations. Calculating the values in your controller and supplying it as part of the model would couple the display to the action performed by the controller, i.e., if you simply want to change how the data is displayed -- for example, group by category and show sub-totals -- and expected all the data to be in the model, then you'd have to touch both the controller and the view to make the change. If you put the display-related calculations in the view, then only the view needs to change.

The call on whether the logic is business-related or view-related is heavily context dependent. For example, you might have a business rule that says you only display products that are available. Enforcing this rule certainly shouldn't be a function of the view so, in that case, you should move it into the controller (or even the model). But if it's a simple calculation of the contents of a shopping cart or filtering what you display based on model properties, I'd be ok with it in the view.

Answer 2

I would push this logic back into the controller and the "view model". I consider this to be the "model of the view". A simple example would be

return View(new ProductSummaryViewModel
{
    Products = products,
    TotalPrice = products.Sum(p => p.Price)
});

You can obviously extend this for whatever the view has to display. You can even have collections of sub-viewmodels which can make things a lot easier.

Hope this helps