C# - Class Design For Reports In .NET Application That Use A Conglomeration Of Data?

I can articulate my question well enough to get some clear and usable feedback here. I have reports (like paper reports) in my .NET application that have data bound to them. Typically the reports are a combination of many data elements across several busniess entites that may not all relate through an Inheritance hierarcy, etc. This makes it difficult to get all the needed data placed together to bind to the report.

So what I have done before are make 'Report' classes with data elements specific to supporting the reports they are bound to, and on the back end might be tied to specially created Stored Procedures that bring this data back (maybe several joins across many tables to get the right data needed). So if I was to make an analogy to the database world, I am essentially 'denormailizing' the data structure to get all of this data into a single class to make it easy to bind to the report.

However on the hard line OOP concepts and architecture design, one could say that a report is just another 'thing' to bind data to, and its class should not be designed just to suit the needs of data binding. In this thought process, I would actually need to make my class design be able to create the relationships needed to get all of the data together properly to still be bound, but not create any special 'Report' classes. I find this difficult to do sometimes. It is much easier to create these relationships in the back end stored procedures and then just output the resultset to be almost immediately bound to the report.

So what is the right way to solve this? If I create these specialized report classes with really no behavior, am I introducing an anti-pattern like the Anemic Domain Model?I could use some feedback, and please speak up if my question and scenarios did not make sense.