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

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 2

Your coworker is utterly, horribly, wrong.

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.

Answer 4

There won't be too many significant differences if you run it on small case levels. So testing it with a small page is kind of difficult to do. You'll find performance differences with more complex use cases (such as with your portal).

While I understand you are using WebForms, take a look at ASP.NET MVC, or ANY MVC framework for that matter, for guidance.

1. Anything that is generated as a view goes into the ASPX page
2. Anything that dictates what gets put into the view (the controller) is put in the code behind
3. Anything that is used to represent what will go into the view is in its class.
4. Anything that is meant to be the general presentation of your site should go in a Master page.

When you do everything in the code behind (JavaScript included) you lose out on more than just performance issues with RAM/CPU. You lose personal time, since you have to compile each and every time you want to update the UI or client side script of your web site. Then you also have to mess with the DLLs on your server, instead of just the ASPX page.

Time is money, friend.