views:

727

answers:

8

I realize that by asking this question, I could have started the apocalypse, but a colleague of mine uses a lot of inline coding in their aspx pages, where as I prefer using the code-behind.

Is there a right and a wrong way here?

+4  A: 

Code-behind is the more traditional and logical place. If it works, it works, but I can't stand doing it in the aspx.

scrot
I know what you mean, inline to me screams Classic ASP. The only problem with using the code-behind I have is that I can't also inherit another page. At least I don't think so. Whereas with my colleagues argument, they can inherit a page and use the code inline which solves this problem. This debate was infact started via this very problem.
Liam
I think asp.net MVC goes back to inlining, to some extent. History repeats itself.
shahkalpesh
+5  A: 

Not unless your coding standard says otherwise.

IMO code-behind helps separation of concerns, so I prefer that, but sometimes just dealing with one file is nice too.

Matthew Jones
+1  A: 

I made the exact post a while back:

http://stackoverflow.com/questions/702343/ondatabinding-vs-inline-pros-cons-and-overhead

I prefer the code behind. I usually have a #region area for all the databinding stuff. It allows for people skilled in HTML / CSS to tweak the HTML and all they have to know is what basic controls to use and to define the OnDataBinding event in the control's definition. They can move things around and do whatever and have no knowledge of what it actually takes to get the data into that databind as it might not be as simple as just a basic 'Eval("something");.

Kelsey
Ah I didn't see that. Sorry for the effective double post.
Liam
The searching doesn't always turn up dups, I have done it as well in the past ;)
Kelsey
A: 

There is no right/wrong with either of this.

You can write some code inline & some of it should be written in code-behind. It can't be absolute. Depends on how readable/maintainable it becomes when you write it on the other side.

EDIT: As it is said, write code for human & incidentally for the compiler.

shahkalpesh
A: 

I tend to use the code-behind since it is the only way for WPF and I try to stay consistant and it feels more natural. But thats subjective.

Nate Bross
A: 

Well, there's inline code, and then there's inline code. If you have a script block at the top for you page_load, that's just fine. But if you're mixing a lot of bee-stings (<% %>) in with the markup, you'll eventually start to have trouble when those bee-stings don't work as you would like with other server controls.

Joel Coehoorn
+1  A: 

Personally I prefer compile errors to run-time errors so I put all my logic in code behinds.

Occasionally when I just need a value to show up on the page I'll put <%=SomeValue%> but even then I much prefer to create a label and set it.

Spencer Ruport
A: 

I want to make sure i understand the question - by in-line, do you mean snippets like

<a><% some.asp.net.code %></a>

or do you mean one vs. two files for each page:

page.aspx
page.aspx.cs

?

Because I am NOT a fan of what I call the 'embedded' code in the first example but I DO prefer code and markup in the same file with a < script runat="server">

n8wrl
Inline code to me is both <script runat="server"> and <% %>.Code behind would be page.aspxpage.aspx.cs
Liam
Ah, I see. Well one win for the single-file approach is the abiliy to leverage < pages>< namespaces>... in web.config - doesn't seme to work for seperate code file. Plus, I really haven't had any luck with different page.aspx's reusing the same page.aspx.cs.
n8wrl
Can you not do it through inherits="page"?
Liam