Any OO paradigm developer that has to persist data should be familiar with the concept of using business objects in any reasonable sized project that is n-tier. For most “more than reports” applications that I develop, I use business objects to make accesses data from a front end, or batch program, to simplify the domain to meet the requirements of scenario's solution specification.
A brilliant colleague of mine (don't tell him that, his head is big enough) has been using SQL Reporting Services since prior to our meeting. I had tried to install it on a previous project, and got distracted. I learned that you could basically make reports like you would in Microsoft Access reports, but with more leverage for distribution. You, as a developer, could set up distribution on a shedule, or have users request data in real time on demand.
I had an assignment that need to chart some comparisons. There are tons of .NET controls for charting and graphing out there. But with the effective use I had observed KD user for a different solution, I wanted to leverage the technology in SQL Reporting Services. Our shop has just retooled to .NET 2.0 framework, and as such, none of us has taken the time to train in the new namespaces and components that it brings. Sadly, we have all seen vb 6 code in a .NET 1.1 solution. I would hate to be the guy who writes .NET 1.1 code in .NET 2.0(phewy, I have the recordset, who needs System.Data.SqlClient), but that is another story.
Long story short, I found that there are new controls in ASP.NET 2.0 for data. One of which was the Report Viewer. The Report Viewer allows the developer to create reports, charts, graphs...basically what you can do in Access reports--even scripting. “This is friggin awesome”, I thought. I ran over and told some people around me, but they were not as amused as I was. This happens more than I want to admit.
Now, back to OOP, I thought well how can I use my existing business tier to create this chart. Thinking back to the GridView, and its use of datasource, I thought, “It'd be nice to have a datasource that could use business objects.” Yeah, I know, I know, its included in .NET 2.0. So, by choosing the Report Viewer, creating an rdlc report file, and specifying the objectdatasource, I created the required report in a matter of minutes using some design principles that I knew and leveraging knowledge from my colleague, along with my already created business layer.
I haven't gotten into the distribution part yet, but I assume that I could hook into the Application_OnStart and the Application_OnEnd functions for distribution, or run a job to send emails with at link to the page that has the report viewer.
There are tons of articles about how to configure an objectdatasource around if you search. Since I'm lazy, I'll let it be the reader's exercise to view screenshots there for GridView datasources and apply that knowledge for designing reports and using the objectdatasource in a page used to display it.