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
- It should be designed using traditional MVC pattern, as there is one model and different Views(chart,excel,pdf)
- 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.
Honest answer: It sounds like you are either over-engineering this, or you are irresponsibly re-inventing the wheel.
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.