Moving complex conditional statements to code behind

Question

I was just wondering, if by moving complex if else statements and the resulting html markup to the code behind violates some 'MVC' law?

It seems like a great option when faced with inline if else statements that can become extremely unreadable.

Answer 1

I believe as long as it's a rendering code and it's in a "View" not in a controller, then putting it on code behind or inline won't matter. Just make sure that you don't write this piece of the rendering code in the Controllers actions (this way you will really violate the MVC pattern).

Answer 2

The codebehind is part of the View -- it's up to you if you want to put things in the ASPX directly or in the codebehind. MVC doesn't mean you have to code things all ugly in the ASPX :).

Answer 3

I prefer not to use the code behind class in my views. This is not because it violates MVC by default, but because I found that the "natural" way (at least for me) is different.

When I face complex HTML markup that relates to purely view concerns, I usually write an extension method for HtmlHelper class in order to hide the complexity. Thus I have extensions like Html.MoneyTextBox(), Html.OptionGroup() and Html.Pager<T>.

In other cases when complex conditions arise, usually I missed something from the controller. For example, all issues related to the visibility, readonly or enabled of elements usually stem from something that the controller can provide. In that case instead of passing the model to the view, I create a view model which encapsulates the model and the additional info that the controller can provide in order to simplify the HTML markup. A typical example of view model is the following:

public class CustomerInfo
{
  public Customer Customer { get; set; }
  public bool IsEditable { get; set; }  // e.g. based on current user/role
  public bool NeedFullAddress { get; set; }  // e.g. based on requested action 
  public bool IsEligibleForSomething { get; set; }  // e.g. based on business rule
}

That said, the code behind is part of the view, so you can use it freely, if it fits your needs better.

Answer 4

It's not horrible to have conditionals in your view. I would keep them in the ASPX not the code behind. However, a conditional often indicates controlling behavior. Consider the following ASPX code:

<%if (ViewData["something"] == "foo") {%>
     <%=Html.ActionLink("Save", "Save") %> 
<%}%>
<%if (ViewData["somethingElse"] == "bar") {%>
     <%=Html.ActionLink("Delete", "Delete") %> 
<%}%>

This set of conditionals represents controlling behavior that is being handled by the view -- i.e., in the wrong place. This behavior is not unit testable. Consider instead:

<%foreach (var command in (IList<ICommand>)ViewData["commands"]) {%>
     <%=Html.ActionLink(command) %>
<%}%>

In this example ActionLink is a custom extension of HtmlHelper that takes our own ICommand specification object. The controller action that renders this view populates ViewData["commands"] based on various conditions. In other words, the controller does the controlling. In the unit tests for this action, we can test that the correct set of commands will be presented under various conditions.

At first this might seem like a hassle compared with quickly throwing a few IFs into the view. The question you have to ask yourself is, "Does this IF represent controlling behavior, and do I want to ensure does not at some point break?"