The worst maintenance task ever (a rant)

Published 08 July 04 12:11 AM | alexcampbell

The below started out as a rant against the ASP.Net Forums v1, and became a kind of work-in-progress on my thoughts about the best way of developing high-quality commercial websites under budget and on time.  What follows is partly my belief, partly my devil's advocacy trying to stir up some interesting discussion on this topic.  I want to preface all this by saying that the development work I enjoy the most is object-oriented, and I think OO architecture has a place in nearly everything we do.

Possibly the most painful thing I contemplate in my working life is maintaining an old client web site that uses the ASP.Net Forums v1 to run an online community with thousands of active users and tens of thousands of posts.  Usually, this would be a pointless blog topic, but right now I think it illustrates a lot of what I have been saying about ASP.Net architecture.

My starting position is thus:  the majority of what we do as web application developers is create an interface between a web browser and the persistance medium (usually SQL Server database tables for me).  The decisions that we make about what is in between these two end-points really should have no effect on the end users, all they see is formatted HTML.

The ASP.Net Forums have 5 tiers in between these two end-points.

  • ASPX pages
  • ----------------------------------------------------------------------------
  • Custom server controls
  • Business logic layer (ie Threads class containing static methods)
  • Custom objects (ie Thread and ThreadCollection classes containing the OO data representations of what is in the database)
  • Data Access Layer
  • Stored Procedures in SQL Server
  • ----------------------------------------------------------------------------
  • Database tables in SQL Server

An alternative architecture:

  • ASPX pages
  • ----------------------------------------------------------------------------
  • Codebehind containing SQL queries / statements
  • ----------------------------------------------------------------------------
  • Database tables in SQL Server

Try this test: pick an average person on the street.  Choose someone who is accompanied by an attractive member of the opposite sex so you can be sure they're not a professional software engineer.  Get this layperson to tell you about their favorite websites, and you will find that they have no idea how many tiers there are in between them and the data they see.  You will almost certainly find that the most interesting sites to the user are the ones that have been able to adapt to users needs more quickly - the ones that have the least tiers.  Users don't care what's happening behind the scenes - they're looking for information.

Let's say I wanted to add voting functionality so that users could rate each post (ie like Slashdot).  To do this on the 7 tier architecture, I could spend two weeks working up and down each of the tiers.  Extra tiers make maintaining/enhancing a site far more difficult.

It's also worth mentioning that the most useful sites to end users are sites whose construction didn't bankrupt their owners during the construction phase.  I'm convinced that the 7 tier site above costs two or three times as much to develop as the 3 tier alternative.  A clever company that is starting an online community would want the 3 tier site and use the money they save on site enhancements after 6 months of watching their users.  Successful web applications are able to change rapidly based on user feedback.

The craziest part of all this is that you can't ever return anything other than a string or a binary file to a web browser.  You can't ever pass a ForumPost object to a web browser and let it figure out how to display it.  All you can do is either Response.Write() strings or use ASP.Net's more refined methods for formatting strings before sending them to browsers (ie DataGrids, Repeaters, Labels).  The database might be a bit more clever - SQL Server provides a whole stack of datatypes for you - but all that is doing is ensuring that your datatype and data relationship requirements are being enforced at the persistance medium.  But at the end of the day, you are going to convert these into strings before you send them to Joe Blog's Internet Explorer.  What do you gain from replicating the database structure in your middle tier?

Ok, so the ASP.Net Forums v1 are an extreme example.  But now I go to try to figure out why the Thread sorting mechanism isn't working.  Once I dig through the tiers to figure out which stored procedure is being called, I end up in a file called SqlDataProvider.cs.  It is 4396 lines long.  What a fucking mess.  Why would you put every single data access call for the entire application in ONE file?  I gather that this is considered a best-practise in case you ever want to change database servers (remember when Microsoft went broke and left all its SQL Server customers out to dry... no?).  How many people are using Oracle or mySql to power the ASP.Net forums?  Even if I was forced to rewrite this application tomorrow for Oracle, I don't think this architecture would make it substantially easier.

Fuck, the stored procedure is 200 lines long.  It contains more logic, mostly in the form of if/else if/else statements, none of which are commented or indented.

I'll leave it at that for tonight.  I want to repeat my initial statement: the preceeding is more an attempt at provoking discussion than my own personal views.  :-)

Comments

# TrackBack said on July 7, 2004 12:31 AM:
# Alex Papadimoulis said on July 7, 2004 09:21 AM:

I'm with you there. Do we really need an abstract data provider factory if the platform will never change?

However, one thing to consider is that the ASP.NET Forums was an example, and I think the complexity was demonstrative .... but still .... KISS is all I gotta say.

# m7 said on July 7, 2004 09:26 AM:

while I agree with your sentiments (that the architecture of the forum is not optimal), the architecture you also put across (having asp.net page, codebehind, database only) is flawed, and it's based on your assumption:

"The craziest part of all this is that you can't ever return anything other than a string or a binary file to a web browser."

the architecture is meant to demonstrate good practice for developing applications. its shortsighted to assume that the client will ALWAYS be a web browser. what if a company wanted to take a web app and turn it into a win form app to gain more flexibility of the interface? in your model, lots of copying and pasting of code-behind and HUGE scope for errors. in the current forum model, you just use the business logic classes and everything beneath that just magically works.

not to mention the fact that if you think you have to redevelop anything to change from sql server to oracle, you're kind of missing the point of having the abstract data provider factory in the first place :)

# Thomas Tomiczek said on July 7, 2004 09:44 AM:

I FULLY agree. The ASP.NET forums architecture goes close to be aworst case for me.

We just did a small messageboard (not fully featured yet), and guess what, the db is automatically maintained, the DAL is automatically maintained, it is threee tiered:

* Presentation layer (.aspx, .cs for codebehind)
* Business Layer
* DAL automatically done.

# Scott said on July 7, 2004 12:37 PM:

m7, I think the point Alex is trying to make is. Why go through all that architecture when you KNOW the DB backend won't be changing?

# Paul Wilson said on July 7, 2004 01:05 PM:

Well said -- I've long been afraid to criticize some of these "pet" projects -- yet they truly suck. KISS indeed.

# Mike Hillyer said on July 7, 2004 01:42 PM:

I don't think database abstraction is introduced for the sake of having an alternative when you change the DB backend, but more about giving the users choice when they do the initial install. I appreciate that in an app. Sure, I may never change the backend once I get going, but at least at the start I have freedom to choose what that backend will be.

Of course, doing it well is still an issue.

# Andy Smith said on July 7, 2004 01:45 PM:

One thing to keep in mind about the forums and the database provider thing, is that there is a difference between making an application for one task, and making an application meant to be used by many different people in different circumstances. Obviously, when you are making your application for your one client, things can be a lot simpler in that area. Now, the forums might not be the BEST example of when the database should be plugable, I think it's still a fairly good one.

# Girish said on July 7, 2004 06:03 PM:

Response in link. For some reason, it did not create a trackback.

# Mike Gale said on July 7, 2004 06:24 PM:

Good to open people's minds.

A lot of people go down the "it must be in a database" and it must "run some code". I've seen cases where all you need as a backing store is a file with an htm or aspx extension. Now that's something computers know how to do, file serving. Performs like a demon. Even if the "owner" needs talking out of some bells and whistles!!

# m7 said on July 8, 2004 04:21 AM:

<<
Why go through all that architecture when you KNOW the DB backend won't be changing?
>>

who said you should? the sample was to allow people to install on any database. therefore it had to be developed WITH the need for the backend to be SQL Server OR Oracle OR whatever.

# KZander said on July 8, 2004 09:39 AM:

This is dangerous thought. Not abastracting the database backend? This is obviously not a enterprise perspective. In an enterprise there are many database environments and pressure to CHANGE QUICKLY from one to the other is always just around the corner -- ie issues of scale. I've not looked at ASP.NET forums, but I don't agree with lockin to the point that we have no leverage with Microsoft when it comes to licensing agreements.