I am curious as to which reporting tool would work best with CSLA Business Objects. Crystal Reports is the current solution, but I am looking for a new solution. MS Report Viewer seems like a possibility. I have read that MSRV works with CSLA BO. Is that correct? Please advise to the most appropriate reporting tool for working with CSLA BOs.
Thank you in advance
Generally speaking I divide "reports" into two categories:
Lists can be generated from business objects or other in-memory data, or from data in a database. Since the amount of data required to generate the list is small it doesn't matter a lot where the data comes from.
Reports can only be generated directly from the database by using a report generation tool. The overhead of retrieving large amounts of data into objects and then generating the report is simply unworkable.
Most people, in my observation, treat everything like a report. If they have lists, they'll often generate the output using Word or Excel exports.
I appreciate your response, but am, unfortunately, new to CSLA and need a more direct answer. Do Crystal Reports and Microsoft Report Viewer both play well with CSLA business objects? If so, which, in your opinion, would be the best?
Thank you
I can't answer with certainty, but I can say this.
CSLA objects are bindable - that's a primary feature of CSLA. Objects built using CSLA are bindable in Windows Forms, WPF, Silverlight, WP7, Web Forms and ASP.NET MVC. Literally every binding technology Microsoft has invented for UI technologies is supported by CSLA.
So any reporting tool that can generate reports from bindable objects should be able to work against CSLA objects.
Thank you for the response - a speedy one at that.
Hi,
both do play with CSLA-objects, but more or less well 
I compared both for usage as, let's say a printing engine, therefore printing single objects and lists. CR had to be a little forced to even see a BO that doesn't reside in the same solution at designtime as it's the case most often, since printing in my case definitly is a client-side UI concern and my BO's reside in a different dll (which is kind of standard).
Because of ease of deployment and smaller overhead, I went the MS path. CR always has this 'hey I'm used to work as a standalone reporting/BI tool', but sometimes it integrates even better into your app as MS does (just try to establish your own toolbar into the preview!).
Printing/reporting seems definitly not the strongest part in the OOP toolset in todays dev-world in my opinion...
HTH
Volker
Hi,
Like Rocky already wrote:
1. A full fledged reporting solution is better based on the server version of ReportingServices with direct SQL to the DB.
2. For data that you load in grids/forms in your app you may use ReportViewer to generate nicer looking and printable reports using MS ReportViewer in "local report" mode. This will also allow you to export data/report to excel or pdf format.
For more info, FAQ and samples on how to use the MS ReportViewer with objects goto http://www.gotreportviewer.com
We use MS ReportViewer in "local report" mode to generate reports on data we already have in memory (not meant to be a reporting solution) and this works nice. A little cumbersome to define subreports and supply data to subreports but once you get used to it it works fine. Also nice to know that this is integrated into VisualStudio and no license costs.
Thank you all for your responses. This information has been very beneficial to me.
Personnally I strongly prefer to use Reporting Services for report design, hosting and execution + a WCF service which returns a list of dtos. The WCF service calls a BO or command which is responsible of generating the dto list and it is fully testable. I then bind the dtos in the report using an XML data source. The report itself contains only data presentation and formatting, no formula or logic at all. Yes, even when using a fairly complex tablix in reporting services 2008. Works like a charm!
You might think it produces a slow report but you could be surprised of the performance. We use a lot of multithreading in the BO or command with proper resource access management and we get fine results. For example,, if there are 500 000 dtos to process, we split in n lists and treat them separately before combining the results. And more importantly, I am always confident of providing accurate informations to the users since I test thoroughly the algorithms required to produce the report.
Hope this gives you another option!
Copyright (c) Marimer LLC