Question about architecting applications with Report Designer

I'm very new to Report Designer and .Net and someone told me it was best if I just used Stored Procedures to get data for the reports. In my previous work experience, we always avoid tying the presentation layer directly to the Data Access layer. My thought is that it would have been a far better architecture to have the Report Designer pass a request to a Service class which would then invoke the appropriate business object. The C# business object would then access one or many DAOs (Data access objects) to bundle the data from various tables into a value object. The Report Designer could then get it's data from the value object. Our data model is very complex and the Stored proc solution is using far too many intermediate temp tables to hold intermediate results. So, what is the best approach to use when data on a single report page can come from as many as 12 different tables? The report layout requirements are complex too.

Have you tried creating a Report Model?

|||

I'm in the same situation. Did report model help you? Please let me know what decision you have made?

I'm thinking of Custom Data Extensions that retreive entity from BLL and attaches it to the report for display. Did you look at that option of accessing custom .NET code (which will be BLL in our case) from within the reports using assembly references and embedded code. The custom .NET code will return a list or array for display within the reports. I have not tried this and not sure whether this will work.

|||

Hi,

I never had a chance to create the Report Model because of lots of pre-production stuff to do. The project is ending in 2 days now and then I'm off to another client. For the benefit of everyone else, if anyone has ideas on flexible architecture for reports, please post.

|||

Perfect example for using web services.
Create a web service that would expose methods to query data from your complex data storage. Internally your webservice will use your business objects for data access then serialize results into xml and return to the caller.
Then you can use Xml Data Provider in your reports to call SOAP APIs and convert returned xml back into rows and columns. Xml DP will let you pass parameters into soap calls, so it's fully flexible. You can search msdn articles and this forum for more info on XmlDP.

|||

Thanks for your response.

I'm planning on using the Custom Data Extensions. The custom DataReader implementation will instantiate a domain class within the business layer and the class will have method which will return the relevant business entity list or some collection of objects. The collection of business entities will be consumed by the DataReader and iterated within the 'Read' method to display the contents within the report. This way i can leverage my business layer and produce the reports.

Do you see any issues with this approach? Please let me know

|||looks good to me