Architecture for Reporting Web Site

Question

I've alluded to this project before, in this question, but the scope of redesign has been slightly tightened, i.e. I can't redesign the whole thing, so I 'd like some general advice on how to structure the existing artefacts in the application as an incremental step in improving the design.

1. The site has two areas of functionality, v.i.z. reporting and maintenance. This is the major function of the site, not data manipulation, but just presentation. The site includes a small number of maintenance pages that use standard GridViews and FormViews for maintaining a small area of data. This is why I have decided against a rich, complex DAL in favour of the Enterprise Library DAAB and plain vanilla datasets.

2. Each report is an isolated page that uses results of a dynamic SQL query to explicitly render HTML table rows for the report. In order to not maintain one set of queries for both mySQL and MSSQL for each report, I will move all data access to stored procedures, removing coupling to either DB engine through the DAAB.

3. I am looking at reporting tools to decouple the report structure definition from the report presentation. I would prefer to not define report structure in classes, as telerik reporting does, but have yet to look at other reporting tools.

4. All reports share a common filter page that is presented on choosing a report from a menu, which redirects to the chosen report once the user is happy with their filter selections. Is there any guidance available for this very common scenario that I seem to have to keep reinventing?

I am looking for general advice on how to move this toward a better structured product, without actually restructuring the whole project. Simple stuff like separating maintenance pages from report pages in sub-directories, etc.

I'm not looking for others to do my work, and will in due course have implemented many improvements of my own making, but I would appreciate general opinions on how other people would handle a project like this.

Answer 1

For presentation of reports based upon a database of facts I would investigate one of the tools that has got all the core functionality already implemented, such as BIRT (and I am sure that there are some .NET alternatives). You might think a table of data is good enough for an intelligent person to parse, but down the line someone will ask for graphs and PDFs.

The maintenance / admin pages can be a standard website - forms and backend, using whatever framework you are comfortable with.

Architecturally wise, are you going to be running the reports against a live database, or an archive database (or the failover/replication DB)?

Are you generating aggregate data tables (fact tables) to generate reports from, or running against the more complex main schema?

Answer 2

I'm going to go with a management system for metadata on reports, with a simple directory structure for a page-per-report system, using the DevExpress ASPxGridView. This grid is more than capable of meeting the reporting needs of this application.

I'll be implementing maintenance and admin as standard web forms, with a shared filter form for most reports, dynamically configured based on report metadata. There will be no runtime maintenance of reports, as adding a report requires adding a page. This is acceptable as maintenance will be infrequent.