Thursday, July 9, 2009

Overly Complex Webforms: Necessary Evil, or Complexity Problem?

One thing that I encounter quite frequenly are webforms that have very complex and involved logic. I'm thinking specifically of a page that I edited recently with over 2000 lines of code in the code beside. Two thousand lines! I have a hard time wrapping my head around that for a webform.

My honest belief is that a webform really shouldn't contain more than, say, 500 lines of code beside. Yes, that's a pretty arbitrary number, but really, what are you doing on a webform that requires more than 500 lines of code? Sure, there are some pages that require very complex business logic. Complex business logic I understand. What I don't like are webforms that have more than 500 lines of code beside which is almost exclusively GUI programming.

I think that if your code beside requires more than 500 lines of code, then you seriously need to reconsider what exactly you're trying to accomplish with the form. If you're continually adding GUI logic, making this control update that control, and that control updating these controls, then it may be time to start re-evaluating the page to see if there are GUI elements that can be broken out into their own forms.

I realize that it's a fine line that we draw when trying to decide what to show the user all at once and what to require the user to mouse and click to see. It is a bit of a moving target, I'll agree. However, you'll find that as the GUI complexity grows beyond 500 lines of code, the performance of the page starts to suffer. I especially see this on AJAXified webforms. The irony is that the responsiveness that the developer gleans by asynchronous AJAX calls are cancelled out by the amount of processing time required to perform such complex GUI logic.

So what does one do when one sees a webform growing to such monstrous proportions? As mentioned, my advice is to find ways to logically break down the webform into separate components that can be placed on their own forms. This will clean up the logic and increase per-page performance. Also, maintenance programming will be much easier. Nothing sucks like opening up the code beside and having to step through line after line of spaghetti logic just to fix one line of code.

There is another solution to this problem, and that is the use of user controls. I'm a big fan of user controls, but I'll touch on that subject on another post.

1 comment:

Chris Benard said...

User controls! Exactly! I was all fired up to write that as a comment, but then your last sentence killed it for me. I completely agree with that method of modularizing, or in other words, "separation of concerns".

One thing to think about though, with AJAX, is that usually, even with complex business logic, the CPU time to compute the page output is going to be far less than the bandwidth constrictions and latency to transfer it. Combining this with the much faster JavaScript engines of modern browsers means that AJAX is indeed a very fast way to update pages, even if the user interface is a bit complex.

What is interesting, however, is when you do your page layout decisions in client-side DOM manipulation, rather than relying on AjaxPanel. For instance, a DataGrid can be placed in an AjaxPanel and updated automatically in ASP.Net using AJAX. But what if, instead you create a web service that spits out JSON and then create the grid client side? You can compress the JSON in transit using gzip compression via HTTP, and this is far faster than the built-in way of doing it in ASP.Net.

What is unfortunate is that this takes a bit longer and is more complex, but results in a faster page. Whether or not this is a constraint relies upon managerial decisions which may or may not be in your control.