Hopefully 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. Thanks!
There is nothing wrong with having your domain model (simply – data used in your business logic) shaped differently than the data in your database. In other words, you don’t have to have one to one correlations.
With this in mind, there is nothing inherently wrong with creating report objects that act like property bags of data sets to render different parts of a report. In fact, since the reports are read only, it is often preferable.
Now, you can set things up so the business logics are more aligned with the database rows and create a view model for the report. This may, or may not, lead to greater reusability. Determination of where to create the shapes that the report binds to is largely dependent on whether or not the datasets make sense as bits you can consume for some business function. If they are truly related to the report only, then consider creating the report classes once and passing them through the business tier.
Hope this makes sense, as I don’t think it was my best answer post lately. 😉