ASP.NET - Inline vs. Code-Behind

Question

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?

Tomas

Dupe of #702843 – Endways

Yeah, Kelsey pointed it out. Though not quite the same, I'm looking for if there's a correct way of doing things, mostly for a project we're about to start work on. – Tomas

Answer 1

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.

Bulky

Answer 2

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

Centralize

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

I think asp.net MVC goes back to inlining, to some extent. History repeats itself. – Kwashiorkor

Answer 3

I made the exact post a while back:

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");.

Beecher

Ah I didn't see that. Sorry for the effective double post. – Tomas

The searching doesn't always turn up dups, I have done it as well in the past ;) – Beecher

Answer 4

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.

Eyeful

Answer 5

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.

Retain

Answer 6

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

Canonist

Inline code to me is both <script runat="server"> and <% %>. Code behind would be page.aspx page.aspx.cs – Tomas

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

Can you not do it through inherits="page"? – Tomas

Answer 7

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.

Kwashiorkor

Answer 8

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.

Cist