ASP.NET: Code behind or no code behind?

Question

Why would anyone want to not use a code behind file so that server sided code is separated from markup? Wasn't that supposed to be one of the advantages of .NET over classic ASP?

Personally, I think mixing code with markup makes the code a lot harder to understand.

I hate to see those darn <% %> (server sided blocks) inter-spliced in with markup, yuck. I would expect that this is in ASP.NET solely for backward compatibility with Classic ASP but I see examples from MS all the time that include those yellow brackets.

I am trying to understand a code example which is available for download here and puzzled at why any of my server-sided breaks shown here don't break when executing the code even though I see that has been set in the web.config. Since I usually work with code-behinds, I am wondering if there is something about server-side code in the aspx that is handled differently that is preventing me from debugging the runat=server code.

So. My questions are:

1) Why would anyone want to not use a code behind file so that server sided code is separated from markup?

2) Why might I not be able to break on the server sided logic?

Your insight and opinions are also welcomed on any of my related comments.

Answer 1

The inline code ability using <% %> is not just for backward compatibility, but a feature of .NET that can allow for some (relatively!) clear and straightforward solutions. It is however often used in a less than ideal way. Likewise, code in the code-behind if often (usually in fact) used in a less than ideal way, as are web-controls.

Having code in the code-behind typically does not serve to separate concerns, but to have jumbled spaghetti code in a different place than we had it in classic asp. .NET does allow you to have very well organized solutions, but it's up to you to make it happen. Having code in code behind pages is not the first step in that journey, just where that journey can begin.

As to why your events are not firing, most likely:

• The event is not actually being triggered. (Are you changes the selected item in the drop-down list, to actually trigger that event?)
• You do not actually have the event wired up. In the properties window for that control, is the event function name listed corresponding to the event in question? (this is the most straightforward way; you can also use the handles keywork in vb, for example)
• Often when my events are not firing, it because I'm doing something stupid like not having started my code, or my url is pointing to the wrong place.

Answer 2

1) I guess if you're used to developing classic ASP, then its an easy transition.

2) Without seeing your markup, I wouldn't be able to tell you what your issue is. If you're not hitting that breakpoint, there could be one of a few reasons:

1. Debugging might be disabled
2. The event isn't taking place
3. There is nothing in your markup telling the control that your method is there as a handler for the event.

Answer 3

The brackets used in most of the MS examples are usually for function calls or referencing a databinder.

For example,<%# Databinder.Eval("MyColumn") %> would be used in a repeater.

There are also tags that are used to reference web.config attributes like the connection string <%$ConnectionStrings:NorthwindConnection %>

Answer 4

Very often "sample" ASP.NET code is distributed with inline code simply because, well, it's easier to distribute that way. It's self-contained, you can just copy and paste it into notepad, save it as an .aspx in the folder for a test site, and see how it runs. It's probably not something you want to do in production.

As for the more general question... ASP.NET MVC is technically still ASP.NET and does not use code-behind files. Many developers feel that code-behind files just traded one type of ugliness for another; personally, I can see it from both sides, but I think the real reason for so much lousy code in classic ASP wasn't the tag soup, but the fact that people were doing insane things in "view" code like opening up database connections. As long as you don't do that kind of thing, a few server tags are not a big deal at all.

In fact, if you do any data binding you're going to have a bunch of Eval and Bind tags mixed in with the markup. So even pure WebForms with code-behind isn't always squeaky-clean.