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: 
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.
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 :).