4

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?

Jon Seigel
  • 12,251
  • 8
  • 58
  • 92
Sameet
  • 2,191
  • 7
  • 28
  • 55
  • 8
    I think the answer you're looking for is "no, that is not right". – Brad Wilson May 17 '09 at 06:29
  • So sir, how much is too much? Is 2600 + 1600 acceptable? For an ASP .NET page or a web page in general, is there a figurative limit on LOC before it leads to performance issues? The page size so far is 180 KB...what should be the cut-off on that? – Sameet May 17 '09 at 07:01
  • An ASP.NET page should be about presentation and presentation logic, and nothing else. Any business logic, any model manipulation, etc., belongs in another class. – Brad Wilson May 18 '09 at 05:18
  • I've always been taught "Code as if the next guy to maintain your code is a homicidal maniac who knows where you live." - Kathy Sierra and Bert Bates. I.E I would never leave 5000 lines of code in one page. – Thomas Lindvall Jul 13 '14 at 17:07

11 Answers11

5

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

Sayed Ibrahim Hashimi
  • 43,864
  • 17
  • 144
  • 178
  • whereas the html generated for this page of stackoverflow itself is more than 1300 lines... – Sameet May 18 '09 at 06:23
3

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
  • 4,925
  • 3
  • 28
  • 38
  • 1
    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 May 18 '09 at 03:28
  • 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 May 28 '09 at 08:31
2

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
  • 36,858
  • 7
  • 80
  • 143
1

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
  • 1,772
  • 1
  • 13
  • 19
1

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?

Brian Webster
  • 30,033
  • 48
  • 152
  • 225
corlettk
  • 13,288
  • 7
  • 38
  • 52
1

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
  • 28,023
  • 6
  • 71
  • 62
0

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.

Joe
  • 1
  • 1
    The server doesn't have to search for functions, and the functions shouldn't be on another page. There is no excuse for such a huge class, regardless of the type of class. Clearly, you don't unit test any of that huge volume of code. – John Saunders Dec 29 '11 at 21:29
0

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
  • 155,851
  • 29
  • 291
  • 343
0

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.

0

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

Hannoun Yassir
  • 20,583
  • 23
  • 77
  • 112
0

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
  • 5,523
  • 1
  • 23
  • 28