views:

82

answers:

2

I have an ASP.NET web site dedicated to reporting on PBX extension stats. It comprises many report pages, with HTML generated almost purely by code-behind (setting a Label control's Text property instead of using Response.Write), using un-parameterised string literal SQL queries that populate By Reference DataTable parameters.

Maintenance pages at least comprise DataGrids and detail forms, but use the same DAL, on e thing for which can be said is that it supports multiple DB servers, with sub-classes each overriding these access methods with their own string literal queries.

What do I need to consider cleaning up this mess? I've already made an almost obvious decision to use a third party reporting solution, and move the queries to stored procs in their respective DB languages, narrowing the diversity of the different DAL classes, and to separate CSS out to shared files, as lots of it is very hidden in C# files!

+1  A: 

For your back-end design, I suggest having a class to represent each main table of your database (i.e. a Report class and a User class, for example). Anything that's not an event handler should go in the back-end class files / namespace.

For your GUI, looks like you're on the right track using ASP.NET controls instead of just streaming your data out to the user. However, you may consider objectifying the areas of the page. For example, one of my favorite tricks is to open semitransparent "popup" panels when requiring user input or a something like the Information Bar when displaying a short message.

Consider AJAX and the AJAX Control Toolkit. It's easy to implement (especially in the case of a rewrite) and provides great flexibility. Specifically, I've found Accordions - sometimes even nested within other Accordions - are excellent at organizing overabundances of information.

Edit:

Note that if you were to use AJAX, you basically can't even consider using response.write anymore.

As far as having too much content on the screen, remember Panels have a "Scrollbar" property and DIVs don't without some heavy changes.

Also, I tend to separate my code files by Namespace; but the popular trend is to do so by Class. This is a better option if you have many Developers or if it's likely several classes within a namespace will be checked out or simultaneously modified by different people.

tsilb
I like the accordion too but none of my customers ever have. :(
cfeduke
The problem with the Accordion is that you generally don't know the Pane headers are collapsible unless you've tried it or developed it :) Alternatively you can just use Panels and populate them via UpdatePanels...
tsilb
A: 

I would consider ditching any custom written DAL and use one of:

You might even end up dropping sprocs entirely.

If you're daring you could try the redesign using Microsoft's MVC implementation.

Whatever approach you take, make sure you write unit tests prior to refactoring any code, verify the tests pass before and after refactoring.

cfeduke
I'd suggest against dropping sprocs unless you plan to move to LINQ. Parameterized SQL is okay, though it still kinda gives me the chills. The important thing is that you avoid inline SQL queries with direct user input at all costs; and even then run it through rigorous checks. Call me paranoid.
tsilb
Not at all, I just got a friendly slap through that a few days ago.
ProfK