Codebehind files in ASP.NET MVC *ARE NOT* evil
Steve Smith has an interesting post with a suggestive name: “Codebehind files in ASP.NET MVC are evil”. So, it seemed appropriate to write a response with the title “Codebehind files in ASP.NET MVC *are not* evil”. I just couldn’t resist it :)
Technically, they must be there for you to get intellisense on your aspx files, but that’s not why I’m saying they shouldn’t be removed. Before going on, I understand Steve’s point of view: keeping the codebehind files might lead you to put code that belongs to the controller on the view. As I said, I understand, but I want to believe that a good developer will understand MVCs strenghts and will, after some time, have no doubts on where some behaviour (code) should go.
On the other hand, I’m not sure that removing the codebehind file will be enough for stopping a “bad” programmer. After all, he can still put the code on the aspx file because he can still add <% %> to a page and put some server code inside it(and, of course, there’s still the <script runat=”server”> element). So, even though I understand the need for helping a fellow programmer understanding MVC, I hope to have demonstrated that if I’m a “bad” ASP.NET programmer, I can still be “bad” on ASP.NET MVC, even though there is no codebehind file.So, removing the codebehind file is just limiting my options and not preventing developers from writing bad code.
I’m also not sure I agree with Steve when he says that views should be dumb. Once again, you can say that I’m being picky, but I can assure you that my views are not dumb…no, they‘re really smart! You see, they’re smart enough to “understand” that they can’t have any business logic in them. The only code you’ll find is presentation related code. And do notice that even though there might be cases where the view uses a color X to present result Y and color Z to present result W, you won’t find any of those rules “embedded” on my views. In other words, you won’t find any method that looks like this:
return ( myObject.Price > 10 && myObject.Price < 100 ) ? “cssClassY” : “cssClassZ”;
Btw, and since we’re talking about this example, I don’t agree with Steve when he says that the css class info should be passed to the view from the controller. I’m not even sure that the controller is the place for taking business decisions, but we’ll leave that discussion for a future post (I do tend do be super-protective with my domain model and I prefer to see the controller as something that coordinates interactions between views and model). Going back to the color scenario, I think that the object passed to the view should be responsible for flagging special conditions and the view should be responsible for picking up the correct css (after all, CSS are all about presentation and presentation decisions should be taken by the view). What this means is that I’d write the previous code so that it looks like this:
return myObject.IsInSpecialPriceInterval() ? “cssX” : “cssY”;
As you might expect, I want to have the chance to write this code on my codebehind file without having to mix it with the markup of my ASPX page. Ok, by now I think there shouldn’t be any doubts that there are cases where codebehind files are useful (and of course, I think that my previous example might have shown how easy it is to propagate busines decisions to the view and vice-versa).
Let me share with you a dream which makes me stick harder with the “pro-codebehind” approach. Wouldn’t it be really cool if we could get a new server side control toolbox similar to the one we’ve got on the Web Forms world but without any of the existing unecessary features (like view state, control state, server side events)? Just think about it for a moment…
Imagine seeing no more of those <% %> floating everywhere on your aspx page…having a clear separation between markup and code, which doesn’t happen with the current view engine. If you want to really imagine it, just compare the old spaghetti ASP code with the elegance of the ASP.NET web forms page but don’t think about events and view state…just concentrate on the markup. Now be honest: do you preffer the spaghetti or the web form’s approach (ok, if we’re talking about eating, I’d go with the spaghetti, but we’re not talking about eating, ok?). If you’re thinking about transition from Web Forms to MVC, which would be best?
So, yes, you can say that I have a dream…a vision…call it whatever you want it. I’m seeing a lightweigth server side control model where I can put server side tags on the page and initialize their values on the codebehind file. And yes, in this case you bet I can’t live without a codebehind file.
Even though this whole new “server control toolbox” is just a dream (and I’m thinking it will stay like that for a long long time), I still want the options of getting my codebehind file. So, if you really must take it away (by default), please do leave the old checkbox option where I can choose to have a codebehind file.
Bottom line: I prefer to have more options, even though that will mean more responsibilities. But again, this is just my opinion and you know what happens with opinions: everyone is entitled to one!