Sep 19

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!

10 comments so far

  1. Craig Shoemaker
    3:12 pm - 9-19-2008


    I know that this stance is not a popular one, so thanks for posting this…

    I have to say I agree with you on both of your major points.

    I am a big proponent of keeping code in its appropriate place. There are times when you simply have presentational logic. Sure I think you should think twice any time you write an “if” statement in your codebehind, but that doesn”t mean it”s NEVER appropriate.

    Why should we hinder the capabilities of the view just b/c we are afraid someone will abuse it? Perhaps we should add a validator to our designer to check to see if people are using tables for layout too! 🙂

    Also I still haven”t heard a compelling reason why we can”t just use a streamlined control model as you suggest. All I have heard is “that”s not how we do it”. Perhaps someone has given a good reason and I just missed it – but light-weight server controls seem to make a lot of sense.

    Thanks for the post!


  2. Mike
    7:08 pm - 9-19-2008

    Well said Craig. I”m tired of bloggers arguing that because something can be abused it should be taken away. Too easy to score page views with that stuff.

  3. celik
    12:44 pm - 9-21-2008

    Well said. Thank you.

  4. @Luis
    7:50 pm - 10-1-2008

    There are times when a code-behind file is absolutely necessary. For those times, I”d like to see a right-click to add the code-behind. For the rest of the vast majority of views, I”d like a template that doesn”t have a code-behind

  5. Maxwell
    12:47 am - 1-21-2009

    I have to say I agree 100% with your comments.

  6. Rusty
    10:18 pm - 3-4-2009

    I agree! Code behind is a perfect way to process presentation _logic_. I believe very strongly that you should perform all your business logic and data processing in and from your controller. You should format things for display and get everything in order before rendering your view. However, things like css class is pure view and should NOT be passed from the controller. I like your example where you check a condition and select the appropriate css class based on a model boolean. Why not select css class in your view? Because the inherent ability to select different views makes the mechanism for changing presentation a property of the view, not the controller. The controller sets the condition, the view presents that appropriately. As a perfect example, imagine an action that renders html when called normally and JSON when called via ajax. In that case, css class is not the correct way to pass the information to the view and is, in fact, a mistake when an ajax call selects the JSON view.

  7. Dave Schinkel
    5:45 am - 4-3-2009

    >>>On the other hand, I’m not sure that removing the codebehind file will be enough for stopping a “bad” programmer

    That”s a weak argument. That”s why you have team standards and code reviews. And you don”t hire dumb programmers that don”t care about these standards when they code.

    If you communicate often these standards to your team, then the worry about spaghetti in your View should not be so and therefore get rid of code-behind. The entire point of MVC is to use controllers.

  8. luisabreu
    8:11 am - 4-3-2009

    Yes, it is…but It”s the one that has been most used to justify the change. and when you think about it, it”s really as weak as yours…if your programmers are really “smart” and follow your standards, then having or not having a code-behind file isn”t really that important, right?

    Regarding the spaghetti approach, well, if you use the available bits and decide to go with the web form view engine, there”s not much you can do about it: you”ll end up having lots of through your code.

    And I don”t agree with you…the entire point of MVC is not to use controllers. In my opinion, its advantage is the division of responsibilities (I might be stating the obvious, but the view is code too!)

  9. Buy Ambien
    9:48 am - 2-13-2010

    edvins pasa prakahar biopsy finalised invokes faults summarizes dksbz varian rokus
    ambisoltersos makalavertonicos

  10. Sha
    5:50 pm - 3-4-2010

    I agree completely with the author. It”s nice to have code behind for presentation logic.
    It”s like going back to classic asp days where everything has to be done in the page.