ASP.NET web application - 5000 lines of code in 1 page - acceptable?

Question

I'm building an ASP .NET 2.0 (C#) based web application, which is primarily intended for intra-net use, i.e. to be used inside an organization's Local Area Network.

With respect to the User Interface, there are 2 approaches which I need to choose from.

1. Build a 1 page web app, with lots of ASP .NET AJAX 1.0 controls (modal popups) to show categorized content which would otherwise have gone into a separate .aspx page.

2. Use the traditional approach and build multiple pages.

The 1 page UI looks and feels very cool. However, I have doubts with respect to its scalability.

Agreed that the application is intended for use over a LAN, but since it is a web app, it could potentially be used from over the internet if the client wanted to.

Owing to the 1 page UI, there's already around 2600 lines of code in the single .aspx page and another 1600 lines of code in the code-behind (.aspx.cs)

This is going to grow - to at most - 10,000 lines of code (10,000 in .aspx and 10,000 in .aspx.cs). So I need to know - how much is too much for an ASP .NET based page - is 2600 + 1600 lines of code okay for Intranet AND Internet access? How about 10,000 lines of code? What is the bottle-neck? Is this single-page approach okay or do I need to fall back to the traditional multiple-page approach?

Answer 1

Before I say what I intend to say I would like to state that I do not think this is a good idea. Any class (ASP.NET) or not that is 5k or 10k lines long needs to be refactored. There are a lot of comments here that keep stating that your download times will be too long. Just because you have an .aspx file that has 5k lines of code embedded or 5k in a code behind file (or both) this doesn't mean that your download times will be significant just because of this. Those lines of code are compiled and executed on the server, they are not passed to the client. So there is not a direct relationship between # of lines of code to download size.

Sayed Ibrahim Hashimi

My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

Answer 2

Regardless of the increased download time for an incredibly bloated single page like that, it would be an absolute nightmare to maintain. I agree with Brad, the single page approach is not right. And I can't think of any way to justify 10k+ lines in a single codebehind.

Answer 3

if you need to have all the functionality in a single web page, I suggest moving the code into separate ascx controls and combining all the ascx's in one aspx

Answer 4

You always shoud think about people who will try to uderstand your code to modify your app after you. Anyway I think one page - this is definitely not acceptable. There is no any "traditional multiple-page approach". If your application contains different actions it should be "multiple-page"

Answer 5

Not ok, split things up into different files by functionality or section.

This is where user controls come in usefull. If this page has business logic place this in a BLL. Same with DAL.

After you have split everything up with DAL, BLL and user controls everything should be a lot more maintainable.

Answer 6

At face value, it sounds like a horror solution to me (I'll bet your DAO is embedded in the view) but it's impossible to say without reviewing the actual code.

And atleast you had the sense to seek another opinion, and other options... Your concerns regarding scalability are valid.

Think carefully about layering your application approriately... How would your monolithic solution stack up to a "properly layered" solution with regards also supporting a WML view?

Answer 7

How much that is too much is impossible to answer. It's not just about the amount, the quality of the code matters as well. The one thing that can be said with certainty is that if you put large amounts of code into a single page, you will have issues maintaining the code. If you are more than one developer working on the application you will for instance need to merge changes in your source control system very frequently, instead of performing simple updates of separate files.

Even if you would implement the application as a single page I would strongly encourage you to encapsulate separate behaviours on the code behind into separate classes that are created an used as needed by the page. But I would personally design the application so that separate behaviours went into separate pages as well.

Answer 8

I'm surprised nobody's mentioned ViewState. I think if you minimize the size of the ViewState (using ascx controls and loading them dynamically), then a well designed "one page solution" is fine.

Answer 9

10k of code on a single page it too much (it might run fine) but can you maintain this code ?? i m not sure anybody can :)

Answer 10

Your numbers are WAY FAR from "OK". In fact they're disastrous to be honest with you...

Start out by stuffing as much as possible of your different concepts into UserControls. Then create some stateful solution to make it possible to dynamically load UserControls into regions of your page.

Answer 11

I have some pages with 2K lines on the .aspx and 10,000+ in the code behind file. I have many function that are not used anywhere else on the site and rely on some viewstate info. In my mind, and this situation, I think this is a performace boost rather than asking the server to search out functions on another page etc. I think sometimes, you just have to do what you have to do and it is what it is. Just try to make your code as efficient as possible.