Best Architecture for Reporting Application in ASP.net ( with dynamic Sources)

Question

Hi

the Requirement in simple words goes like this.

• Its a charting Application ( kinda Dashboard) with multiple views (Charts , PDF and Excel)

• DataSources could be primarily from Oracle but there are other data sources like Excel,flat Files....etc.

• Charting library would be Component art (I would like to try the new asp.net charting but as its already being used in other apps they would like to continue)

As I told you, We have a already have an application which is like basic 3 layered with some DTOs and mostly DataTables;where I feel any data model is tightly coupled with Views, they would like to continue with the same :)

I would like to propose a new architecture for this and I need your honest comments.

I think

1. It should be designed using traditional MVC pattern, as there is one model and different Views(chart,excel,pdf)
2. A Solid Service layer(Enterprise Lib) with 1) Security(Provider model) 2)Data source Abstraction (flat files , oracle , excel) 3) Caching ( each report would have its own refresh time and the data/view can be cached accordingly 4)Error logging 5)Health monitoring

3) using WCF services to expose the views or DTOs

4) Complete AJAX and partial rendering

5) develop a solid wcfservice which would take the datamodel name and view(chart,excel,pdf then returns the view accordingly.

Please guide me, I want to build a loosely coupled and configurable architecture which can be reused.

Answer 1

I recommend the following book: Microsoft® .NET: Architecting Applications for the Enterprise by Dino Esposito; Andrea Saltarello.

They are discussing architecture in a pragmatic way (Yes there are code examples). Many of the things you have mentioned will be described in the book. You will probably not get all the answers but it will inspire you. (They have made a book about Ajax/ASP.NET arch too but I have not read that one)

You want to use a lot of new cool technology, that’s cool. But most important is why do you want to use it, what business value will it add? Ask yourself what do you want to with your product in the future? To be able to figure out today and tomorrows requirement will be the best thing to help you build “loosely coupled and configurable architecture” it will help you more then any of the techs you have choosen.

Answer 2

My motto is always buy before reuse before build. From the requirements, you could be better off buying a COTS BI solution. They have very robust feature sets and provide the capability to do things like charting, pdf/excel export out-of-the-box. There are tons of vendors, Microsoft has their own BI suite. Oracle has theirs, etc...

Answer 3

Consider using a flexible reporting Engine like List&Label which is also used by SAP. Maybe using some kind of ETL Tool + DataWarehouse might be an option for you too (not enough information on your requirements though). Maybe there is some kind of common pattern in the datasource you have not observed so far.

List&Label is pretty powerful, however i have never used it in a web app. Abstracting your DataSources with simple AnnonymousTypes, then translating them to DataSets and doing the rest with List&Label has served me well for a number of small tasks. See modelshredder for a tool that can help you with it.

Answer 4

Honest answer: It sounds like you are either over-engineering this, or you are irresponsibly re-inventing the wheel.

I want to build a loosely coupled and configurable architecture which can be reused.

That's a lovely goal, but is it a requirement of this project? I'm guessing it's not a fundamental requirement, at most a nice-to-have. It seems that the business needs a dashboard with some exportable charts and reports, and you're proposing to build a platform. That's classic over-engineering.

If you really need a reusable platform, it will take considerable effort and skills to build an intuitive, robust, secure, testable, configurable, maintainable reporting platform with sophisticated and trainable authoring tools.

And even if you build a perfect platform, you'll have a custom system that nobody else knows. If you use an established BI/reporting platform, you can hire people who already know the technology or point people at reams of already existent training materials.

In other words, it's going to be difficult and more expensive to build, which is bad, but also difficult and more expensive for the organization to use for years to come, which is worse. I routinely choose build over buy, but reporting is a known problem that has been solved well enough by commercial platforms.

So, sure, that architecture sounds reasonable. And without knowing more about the requirements, it's impossible to judge: maybe you really do need to build this from scratch, but from your description "charting Application ( kinda Dashboard)", building a reporting platform sounds unnecessary, though perhaps quite fun.

Answer 5

I think you can make a loosely coupled architecture that is flexible. It is actually pretty simple. Create a table that contains all of your reporting SQL and bind the results to a gridview. The individual SQL is pulled from the tables via a drop-down menu of categories and reports. You can add additional tables with sub-selects to drill down and rebind upon row selection. Use the parameters from the Oracle Data Access to include dates, filters, etc. from any controls that may be present on the front-end.

Once the data is dynamically bound and displayed, give the users the option to email the grid contents, export to PDF, Excel, etc.

I've implemented this @ 2 client sites and it saves them a ton of money of buying licenses from Crystal, MS, etc. and is much more flexible.