views:

611

answers:

12

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?

+3  A: 

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.

Jon Freeland
Just wanted to add onto your comment: Modularity is an important paradigm to follow. Try decomposing the components used into usable chunks. Don't go crazy because you still have to maintain the code, but I would suspect with that much code, you have a God Object anti-pattern going on.http://en.wikipedia.org/wiki/God_object
Wayne Hartman
Download time is not proportional to the number of controls on a page / size of codebehind: viewstate means controls that are disabled / hidden are not rendered to the client.
iAn
+4  A: 

You should get rid of the code-behind page and put all of the code in a <script runat='server'> tag. This way you can get all 20,000 lines in a single file.

Shawn Simon
I agree, there's no reason to spread code all over the site if you can concentrate it at one place.
Simon Svensson
LOL .
Greg B
+1 for sarcasm :)
Mischa Kroon
A: 

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.

Fredrik Mörk
+1  A: 

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?

Cheers. Keith.

corlettk
+2  A: 

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

devio
+1  A: 

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"

eu-ge-ne
A: 

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.

A: 

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 :)

Yassir
A: 

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.

Thomas Hansen
A: 

NO!...........................................................

abmv
+3  A: 

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
yes, the html generated is approximately 900 lines.
SaM
whereas the html generated for this page of stackoverflow itself is more than 1300 lines...
SaM
+1  A: 

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.

Mischa Kroon