Designing all pages completely in the codebehind?

Question

Our current web portal at work was a port from a classic ASP codebase. Currently, all pages in our project extend a custom Page class called PortalPage. It handles login/logout, provides access to a public User object for the currently authenticated user, and adds the standard page header and footer to all of our pages.

Every Page in our site is 100% designed in the codebehind. The ASPX page is not used at all. Every single div, img, and block of text is allocated as an object and added from a C# function, even if it is completely static content (which we have a decent amount of).

Example for a page header:

HtmlGenericControl wrapperDiv = new HtmlGeneric("div");
HtmlAnchor bannerLink = new HtmlAnchor();
HtmlImage banner = new HtmlImage();

bannerLink.HRef = "index.aspx";
banner.Src = "mybanner.png";
banner.Alt = "My Site";

bannerLink.Controls.Add(banner);
wrapperDiv.Controls.Add(bannerLink);
this.Page.Controls.Add(wrapperDiv);

Even worse, all Javascript is added to the page as a giant mess of string concatenations:

ClientScript.RegisterClientScriptBlock(this.GetType(), "javascript", @"
    <script language='javascript'>
        fullUrl = '" + ConfigurationManager.AppSettings["fullUrl"].ToString() + @"';
        function showModule()
        {
            $('#" + this.userModule.ClientID + @"').css('display','block');
            $('#" + this.groupModule.ClientID + @"').css('display','none');
            $('#" + this.listsModule.ClientID + @"').css('display','none');
            $('#" + this.labelsModule.ClientID + @"').css('display','none');
        }

Currently, one of my coworkers is arguing that allocating every object in the codebehind is hundreds of times faster than using the ASPX w/ Codebehind approach that I see every other web app using. This goes against my instincts, as it's essentially adding runat="server" to every piece of HTML on the page.

He also says that all professional shops write code this way and never use ASPX pages. He says that all textbooks and sample code uses ASPX pages because they're easier for newbie coders to understand. Is there truth to this, or are we just writing in an incredibly inefficient way for the sake of tradition?

In order for us to switch to the "standard" way of writing Web Forms, I need to provide some source to show that he's wrong.

My problem is, I've never even heard of anyone else writing everything in the codebehind. Every example I've seen uses ASPX pages for the user interface and a code-behind for logic, database calls, etc.

So in summary:
1) Are ASPX pages really that much slower than 100% codebehind?
2) Do professional shops actually use 100% codebehind?
3) If ASPX w/ codebehind is the way to go, does anyone have any creditable links that could help back me up?

Answer 1

Your coworker is utterly, horribly, wrong.

Answer 2

1. They all get compiled to assemblies. The .aspx gets loaded once at application startup and parsed once.
2. No, not if they have any sense.
3. Look at every book at website about ASP.NET. They all use .aspx.

One way to test this is to run a performance test, with two .aspx pages that are entirely identical. Apart from a possible short startup delay for the .aspx (parse and compile), I doubt any significant difference will be detected.

Using all code behind is a way to miss out on:

• Working with designers who understand HTML
• Being able to visually inspect the markup
• Being able to easily change layouts
• Getting experienced asp.net developers to work with you...
• Having a sane way of developing asp.net
• The great tooling and existing integration

Answer 3

I don't even know where to begin with this.

I can't speak to the performance concerns - but I've worked on dozens and dozens of WebForms apps, and not a single one had an issue where the performance bottleneck had to do with using the aspx page.

This just sounds like a complete nightmare.

1. Presentation stuff goes in the aspx.

2. Event handlers go in the codebehind

3. Business logic goes in a separate class altogether.

4. Javascript is your friend, and separate js files are there for you to maintain your sanity.