#viewlogic

If you think you know MVC and View Logic you can probably skip down to the actual controversy. I have believed this to be an easy sell to put View Logic in Views, however in practice it has been quite difficult.

What Exactly is View Logic?

I have seen a tendency for many developers to put view logic inside controllers. What do I mean by view logic? Lets take an example:

Requirements

If I am a moderator I should see a button letting me remove an inappropriate post.

I should not see this button if I am some random internet hobo.

See that "Remove From Internet Button"?

Well if I am a casual internet fellow I should not see that button. Whether that button shows or not is logic. Furthermore it is view logic.

Where MVC Fits in?

MVC is an acronym for Model View Controller. Isn't that fun. For this post we don't really care even in the slightest of the slightest what the Model is, but if you really want to know it is where all logic that isn't user interaction related goes.  

The Views have the direct responsibility of displaying information to the user. This includes all the fancy whiz-bang we as developers like to use like "textboxes" and "buttons".  

So how do we display a button for only certain power-hungry users like "Remove Inappropriate" post above?

One solution is painting directly on the screens of only these elite few. This has the overreaching effect of providing the button on every site they visit. Surely we don't want to give them that kind of power!

The clever solution decades of computer science has provided for MVC architectures is choosing to Render the markup only if a condition is met. "If a condition is met" - that sounds like an if statement! So this is how we miraculously turn buttons on for some users and not others. We simply check what kind of user they are and then render the markup for the button if they meet the condition(s) for it to show.

Now I will quickly mention here what the controller does. The controller's job is to take requests in get needed information from the model, and then provide it to the view. The controller simply retrieves and provides information based what the user requests. This information is seen through the perspective of the view.

The Controversy

What actually determines if I can see a "Remove Inappropriate Post Button"? Almost certainly this is determined by my current privileges (permissions) on the site I am on. My current privileges are provided by the model. 

So the controller gets the privileges of the user and at this point we can go one of two directions:

Check the rights in the controller and then send a boolean to the view telling the view to show or not show a particular button. This has the benefit of making the views thin since the view simply checks a boolean to see if it should show the button or not.

Simply pass the rights to the view and put the logic in the view. This has the benefit of thinning down the controllers at the expense of adding a small amount more logic to the views.

Frankly I view this logic as View Logic and therefore it belongs in the views. Adding new functionality is made much easier since the likelihood of adding new buttons and doo-dads to show or hide will use the same type of logic is high.

New logic like showing or hiding a button if put in the controllers means modifications in the Views, View Models, and any Controllers using the view...

...in contrast to modification of the view alone.

There is a fundamental trade off and it comes down to where the complexity is. I argue and believe the complexity increase is marginal when this logic is in the views and significant when put in the controllers.

As a consequence in general, maintainability suffers when view logic is put in the controllers.

What about Helpers?

What about them? We can use helper methods to encapsulate more complex view logic in controllers, but we can also do the same in Views.

What about unit testing?

UI concerns are not often unit tested anyway, but helper methods are always an option even in the views.

Is it really worth moving the logic out of the controllers?

Three  design principles come to mind: 

Separation of Concerns, Single Responsibility Principle (SRP), and Don't Repeat Yourself (DRY). All three of these are less satisfied by having view logic in the controllers. It is true now the Views have a little more responsibility, but that responsibility already exists as a concern since at the very least you need to check Boolean "flags" anyway.

I'll end this post by saying I think it's plain ugly to have view logic in the controller. It makes them fatter and seeing "IsShowX" and "IsXVisible" all over the controllers screams dead-kittens to me.