Reporting and MVVM?

[Bradley]

As I'm working with it more intensely, I'm getting the impression that ReportViewer is "the orphan nephew living in the cupboard under the stairs".   It appears to work very differently from the other components.  Data binding just doesn't seem to work as it should.  For example, the ReportViewer works very differently from the RadGridView.  In RadGridView there is an "ItemsSource" property that can be bound to a property in the ViewModel.  However, in ReportViewer there doesn't appear to be anything similar.  The only thing I've found in the examples is a binding to the "ReportSource", but that's a fundamentally different thing.  The "ReportSource" is like the template, which, if we continue the comparison, is like the "RadGridView.Columns".  In my opinion, there really needs to be a good way to bind to the DATA.  It looks like the intent is there, since a report can be built with an "Object Data Source", but I've found no way to bind that to dynamic data in the ViewModel, per se. 

Please tell me I'm wrong and point me to an example where the "ReportSource" is configured declaratively in the ReportViewer, but the data comes directly (and simply) from the ViewModel.

Thanks!

[Momchil]

Hello Bradley,

Indeed, the Harry Potter comparison works if we look at the WPF Report Viewer as a traditional WPF XAML+C# component, rather than a platform-agnostic rendering solution.

Telerik Reporting is a .NET reporting tool that lets you design, export, and integrate reports in various applications and the WPF Report Viewer is just one of the ways to display reports in applications. In the WPF environment, I look at the viewer as a "window" into the Reporting ecosystem which has its own rules.

Regarding how the reports are bound to data. In the expected scenario, the reports are meant to "get their data" through their data source components rather than "receive it from the outside". When the report is created, the designer instructs the report where to get the data from using the chosen data source, and when the report is integrated into a viewer, the developer uses the report source to tell the viewer which report to render and what report parameters to use.

Thus, the parameter values are what the report "receives externally" and we can use them to pass data through the report source. For example, if you use a CSV or a JSON data source, you can set its data through a report parameter using the approach described in the following article.

How to set the content of JsonDataSource through report parameter

Still, this is not the scenario Telerik Reporting is designed for and I would avoid using it extensively.

Best Regards,
Momchil
Progress Telerik

[Bradley]

This is actually a very good explanation, and helps me understand the thinking behind Reporting.  So in a sense I'm trying to make Reporting do something it was not really intended to do.

Having said that, I would think there would be a LOT of people with similar needs.  I don't want the report to go get its data.  I want to supply the data to it.

You're right - the CSV/JSON example you give feels like a kludge.

I guess all that remains is to ask that Telerik consider tweaking Reporting in such a way that it does more closely resemble "a traditional WPF XAML+C# component".  I wouldn't think it would be all that difficult to do, and that the functionality could be additive rather than replacing or changing the existing Reporting model.

[Momchil]

Hi Bradley,

We discussed your request further in your related support ticket but I will write here too so anyone else who may be interested can stay in the loop.

I have concerns about the feasibility of adding data-binding functionality to the viewers because of the different technologies that need to be supported, how reports with multiple data sources would be handled, report portability, etc.

However, if you feel this functionality will be popular among users, I suggest logging a feature request in our Public Feedback Portal with the details so others can vote for it.

 

[Bradley]

To be honest I'm very surprised this hasn't been requested before - it seems like a huge and obvious deficiency to me, but then as you've explained, the ReportViewer has a different paradigm.

Anyway, I've made the feature request: https://feedback.telerik.com/reporting/1664811-wpf-reportviewer-add-support-for-proper-datasource-binding-to-follow-mvvm-pattern

Thanks again!