Codebehind files in ASP.NET MVC ARE NOT evil

re: Codebehind files in ASP.NET MVC ARE NOT evil

luisabreu — Fri, 03 Apr 2009 08:11:03 GMT

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!)

re: Codebehind files in ASP.NET MVC ARE NOT evil

Dave Schinkel — Fri, 03 Apr 2009 05:45:16 GMT

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

re: Codebehind files in ASP.NET MVC ARE NOT evil

Rusty — Wed, 04 Mar 2009 22:18:38 GMT

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.

re: Codebehind files in ASP.NET MVC ARE NOT evil

Maxwell — Wed, 21 Jan 2009 00:47:23 GMT

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

re: Codebehind files in ASP.NET MVC ARE NOT evil

@Luis — Wed, 01 Oct 2008 19:50:49 GMT

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

re: Codebehind files in ASP.NET MVC ARE NOT evil

celik — Sun, 21 Sep 2008 12:44:42 GMT

Well said. Thank you.

ASP.NET MVC Archived Blog Posts, Page 1

ASP.NET MVC Archived Blog Posts, Page 1 — Sun, 21 Sep 2008 02:25:55 GMT

Pingback from ASP.NET MVC Archived Blog Posts, Page 1

re: Codebehind files in ASP.NET MVC ARE NOT evil

Mike — Fri, 19 Sep 2008 19:08:53 GMT

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.

re: Codebehind files in ASP.NET MVC ARE NOT evil

Craig Shoemaker — Fri, 19 Sep 2008 15:12:56 GMT

Luis:

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!

Craig

Codebehind files in ASP.NET MVC *ARE NOT* evil

re: Codebehind files in ASP.NET MVC *ARE NOT* evil

re: Codebehind files in ASP.NET MVC *ARE NOT* evil

re: Codebehind files in ASP.NET MVC *ARE NOT* evil

re: Codebehind files in ASP.NET MVC *ARE NOT* evil

re: Codebehind files in ASP.NET MVC *ARE NOT* evil

re: Codebehind files in ASP.NET MVC *ARE NOT* evil

ASP.NET MVC Archived Blog Posts, Page 1

re: Codebehind files in ASP.NET MVC *ARE NOT* evil

re: Codebehind files in ASP.NET MVC *ARE NOT* evil

Codebehind files in ASP.NET MVC ARE NOT evil

re: Codebehind files in ASP.NET MVC ARE NOT evil

re: Codebehind files in ASP.NET MVC ARE NOT evil

re: Codebehind files in ASP.NET MVC ARE NOT evil

re: Codebehind files in ASP.NET MVC ARE NOT evil

re: Codebehind files in ASP.NET MVC ARE NOT evil

re: Codebehind files in ASP.NET MVC ARE NOT evil

re: Codebehind files in ASP.NET MVC ARE NOT evil

re: Codebehind files in ASP.NET MVC ARE NOT evil