asp.net inline versus codebehind which do you use and why?

Question

I've done it both ways, and to be honest other than the ability to give the code and webform to two different people (which doesn't happen where I work), I see very little advantage of one method over the other. I can understand how it is nice to have your code in one file, and markup in the other, but I can also understand the ease of having both in a single file.

I don't see how using code-behind enforces any sort of "good" programming, because you can still write crappy code in code-behind, and I've seen some really clean stuff with in-line.

So my real questions, what method are you using? and is there anything you can do programatically with code-behind that simply cannot be done with in-line code? or does it all really come down to the simple matter of "personal preference". Microsoft seems to not take a real stand on one way or the other and performance wise, it seems a wash.

Opinions?

Answer 1

From my experience, I prefer the code behind solution because I like the separation aspect of it.

I mainly use server controls and I've noticed that I can concentrate more easily on the design tasks or programming tasks if I don't mix these two too much.

But, sometimes, I do appreciate the ease of sprinkling <% %> tags.

In the end, you are right, neither will ensure good and readable code, I've seen some awful code behind projects, as well as excellent and readable "inlined" ones.

Bottom line, it's solely depends on your preference.

My 2c.

Answer 2

As a general rule I try to keep my HTML separate from my code. I treat the HTML as a template with holes poked in it (using Labels, Literals... etc), then my code behind can fill those with data. Having this clean seperation feels easier to manage for me.

Answer 3

Personal preference

Definitely. With a large pinch of "level of tolerance for noise".

Jeff recently posted on this, and I tend to agree. If the source is mostly markup then inline code works well, however if the source is mostly code then code behind (and as Jeff notes VB's XML support could really help here).

When you are setting a few values you may find you make a different choice to cases where the structure of the HTML is lost in the code (e.g. when the created HTML is very much determined on the fly).

Where is the right balance?... that's the preference bit.

Answer 4

I prefer spaghetti for my lunch, not in my code editor. :) I think the most important aspect is the separation of concerns. If I use inline C# code in .aspx files it's just for databinding (e.g. building a string from some values), providing ClientID's to JavaScript, etc.

It all comes down to maintanance, I guess. I know I'd rather be fixing your project ;) with code in different files, than huge scripts. By using scripts like this you introduce redundant code and make the lifes of your fellow developers miserable. Maybe you don't work with anyone else - but one day somebody may join the team. I like being able to modify the UI logic w/o touching the layout files. Just think of others! :)

If you use some small scripts which are strictly layout related then go for it.

Answer 5

PLEASE - whatever you do, put your code in a separate file! I would hate to debug your code otherwise.

One of the problems with legacy asp was the fact that everything was on the same page, which after many edits to code, would become unmanageable.

Please do us all a favor and use one of the great features of .NET and separate html from server side code.

Thanks...

:)