2

In the transition from classic ASP to Asp.Net some developers took to putting their server side code in a block at the top of their HTML ala:

<%@ Import Namespace="MyDll" %>

<script runat="server">
    void Page_Load()
    {
    }
</script>

This single-page model has some advantages as Jeff Atwood describes, however, in my experience I have seen nearly all code put in a separate code-behind file in recent times (ie with VS 2008).

Nevertheless, it turns out a colleague strongly prefers the single file (inline) method over the separate code-behind method.

What are the strengths and weaknesses of each approach? (I've noticed that code collapsing and #regions don't seem to be supported. Also the pages get rather long and there is no longer the visual separation of client and server side code. Can you tell I have a preference?)

I realize that variations of this question have been asked before, but I haven't seen anyone actually spell out specifically the pros and cons of each method.

EDIT

Thank you everyone for your thought provoking answers. I'm still hoping for a list of strengths and weaknesses of each method. What are the actual features that each has (or doesn't have)?

Improve this question

5 Answers 5

Reset to default
5

There's no doubt in my mind that the code-behind or mvc models are superior for almost everything you want to do. However, even today I still find myself using inline code for most of my pages. Why? Because there's one big scenario where the inline scripts really shine.

If you have a large amount of legacy ASP Classic code that you don't want to just throw out, including a deep nesting structure, it all lives in one big application, and you want to share that application with your asp.net code, you can just drop inline asp.net pages right in your existing web file system and they'll just work.

This sounds like exactly where your other developer is coming from.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

I hadn't thought of that. In our case, we don't maintain classic ASP code. All of our code is at least .NET 2.0 or greater.
4

Because codebehind is just a class it has all of the advantages like inhertance and interfaces. It also enhances readability.

Single page has mostly been replaced by mvc for applications that focus on outputting data instead of implementing businesslogic.

Improve this answer

2 Comments

Good point, mvc does harken back to the classic asp way of thinking (though much improved).
Wrong, MVC brings business logic where it belongs - to the business classes (model), instead of mixing it with presentation inside the "single page" - spagetti-style.
2

Have you considered looking at ASP.NET MVC instead? It will allow you to overcome this dilemna in a very clean seperation.

Improve this answer

1 Comment

Sure, and we are looking at MVC, but I really would like to know what are the specific strengths and weaknesses of each method.
1

Generally, when working in WebForms, the trend I've seen is to use a code-behind. Many* WebForms applications that I've seen in the field have too much in their code-behinds, and the separation is almost critical just to be able to understand all the logic.

However, in a well-designed app where the UI is only doing a UI job, and passing all the logic and heavy lifting to a different app layer, a single-file solution will often end up being more elegant and easy enough to traverse. In a way, going with the single-file solution may -- in the right hands -- motivate a better separation of concerns, because you don't want that one file (which provides your UI) to get cluttered with a bunch of business logic.

In the ASP.NET MVC model, the default is single-file. This is, again, to stress separation of concerns and good application design. (I do not know off the top of my head if the ASP.NET MVC kit provides a code-behind concept. I have not used it if it does.)

Ultimately, YMMV. Good developers tend to write good code whether it uses the code-behind or single-file model. Bad developers tend to write bad code either way, too.

* Obviously not ALL!

Improve this answer

2 Comments

Excellent point, though given enough post back events on a sufficiently complex page, I've seen even clean code-behind get rather large.
True that. At that point, however, the better design is to start breaking stuff up into user controls and just wiring up the user controls on the page to talk to each other. More effort, but definitely easier to maintain.
-1

Inline code is procedural in nature and lacks separation of concerns...

One of the selling points of ASP.Net was the the code-behind and the server controls. It was thought to be bad to have inline code. This changed when ASP.NET Mvc came on the scene -- inline code became "hip" again.

If I had a choice and all things being equal using the code-behind is a better approach. I strive to keep as much logic/code out of the UI.

Even using the code-behind, while it is a class, it can become a tangled mess. I found that using MVP or some variant of MVC with web forms made development more maintainable in the long run.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.