Recently I have been looking into the integration of Dot Net to Microsoft SQL Server Reporting Services. There are a number of different ways Reporting Services can integrate or take advantage of Dot Net capabilities
You can actually use a Dot Net object and or collection as a data source. A collection can return multiple objects of the same type, much as a DataTable for a traditional data source. It may also be based on a single object, which may have a collection embedded. This might be something like a purchase order with a line item collection for the details.
There are a number of ways to populate the objects used by the report. You can build the objects in a dot net procedure, and assign them to the report object at run time. Another alternative is to establish the object data source prior to report creation, and embed the binding when you create the report itself.
Another way SSRS integrates nicely with Dot Net is in presentation. Report definitions may be embedded in Web Applications using a number of techniques, integrating with a report server, embedding a report viewer, or even integrating with SharePoint, as well as Web Parts. What’s nice is that this integration with your application can be achieved in Windows Forms, MVC, ASP.Net, or even an Angular web site.
As you can see there are a lot of ways to use Reporting Services, and many flexible implementations, one of which may be just right for you. The feature I like the most is the ability to build reports that are not two tiered. You can create a report that may not ever interact with a relational database, or a DataSet. Being able to build your report based on objects, using friendly report definitions is a really big plus.
Take another look at SSRS if you haven’t used it before. Using Data Objects for report bindings opens up a lot of options for features that are not easily done in SQL queries. A good example would be passing a set of parameters to the report for selection.
Cheers,
Ben