In my current consulting gig, I'm working on an application that was developed and delivered by a large offshore company. While the history is somewhat murky, my understanding is that the client wanted an ASP.NET application. This was back in the days of 1.0. The vendor assured the client that they were quite familiar and experienced with ASP.NET. What was actually delivered was the most unusual amalgam of code that I've seen since .NET was released (even in Beta form). It is a wasteful chimera. See particularly the first definition of the word. Essentially, what my client has, is a CGI application with a C# back-end. It is a classic example of "Just because you can, doesn't mean you should ...".
Why do I state this? Certainly, if you look at the folder contents, it LOOKS like an ASP.NET application. There are web pages coded as .aspx files and .aspx.cs files. There are data access projects coded with just straight .cs files. It has layers defined as UI, Business Facade, Business Rules, and Data Access. The .aspx files are wired to the appropriate .aspx.cs files...
Closer examination, and some excruciating code modifications, reveals a "dark underbelly" of the code. Consider the following:
- Almost none of the pages use web server controls. Except for some repeaters added after the product was delivered, everything is done as HTML controls with a "runat='server'" attribute.
- While the .aspx pages do validation, it is ALL done with custom JavaScript code - not a single .net validation control is used. As a consequence, there are no corresponding server side validations done. Not good for a financial institution.
- Hidden fields are used liberally on every page to maintain viewstate - not only in the code behind module, but with custom JavaScript on the page.
- Similarly custom flags are used to determine whether a post is the first post or not.
In effect, the vendor completely ignored almost ALL the benefits of ASP.NET, and re-coded all of the same in custom JavaScript and code behind modules. So, it's not as type-safe as it could be, it's MUCH harder to maintain, and about 60% of the code is totally redundant. That's not counting the inordinate number of useless comment lines such as the following (made up but representative example).
// create the business object
ObjectBusiness objBus = new ObjectBusiness();
Comments such as these are generally created by neophyte object oriented programmers who have to explain what the syntax means.
And finally, most of the code is in the wrong place. Had it been done as a more standard, web-server-control-based ASP.NET application, most of the code would be in the code behind module and would be much smaller. I recently finished modifying a page at this client, and most of the work was done in a 200+ line button click event handler in JavaScript. It has so much spaghetti-code, I eventually had to just put in a slew of "debugger;" statements and walk through the JavaScript. Based on the test runs, I'd say half of the code for the event handler is vestigial.
So what can be done about this? Basically, nothing. The code is what it is. It works for the most part. But it's getting harder and harder to maintain. No one really knows what code can be eliminated. But I'm just contracting here, and my contract ends near the end of December. So now I have a better set of questions to ask of a company when I am interviewed, and it is my turn to interview them.
- Does your application use primarily web server controls, or HTML controls?
- Do you use .NET validation controls?
- Do your pages have a lot of hidden fields?
- Do you have your own code to manage the state of the hidden fields?
Cheers!
