Ok, maybe the title to this post was a little misleading, there have been no studies that actually prove that one way or another if will actually go blind using a CodeBehind, but there have been studies (ok, may just suggestions) that you should NOT use the CodeBehind in a MVC application (for anything other than strongly typing your ViewData).
In standard Asp.net WebForms development the CodeBehind was meant to act as a page controller, but over the years it has turned more into a dumping ground for all sorts of evil code (ie business logic). It is this nasty, ugly code that has given (in part) WebForms a bad image. By continuing to use your code behind in MVC all you are really doing is taking an old nasty technique and applying it to new framework and in turn removing one of the great advantages of MVC.
Part of the beauty of the MVC pattern (notice I said pattern, not framework) is that it helps to enforce Separations of Concerns by pushing logic out of your view and into your controllers.
The controller is NOT to be used in the same manner as Code Behinds in WebForms. The controller should only be responsible for either directional logic or conditional logic.
What is Directional logic? Directional logic is any logic whose role is to determine how and where data should be gathered base on criteria provided by the routed request.
What is Conditional logic? Conditional logic is any logic that will attempt to perform various if/else style checks to determine how to best handle the routed request.
If you find yourself using the codebehind for anything OTHER than strongly typing your ViewData you are probably doing something WRONG.
Here are a few rules to live by when doing MVC
- Keep your Code Behind empty
- Keep your Views simple
- Keep your Controllers light
- Keep your Model fat (domain model that is)
Till next time,
[--- Check out www.dimecasts.net ---]
12-12-2008 7:38 AM