Why would you use a Report Engine, if your application are modeled around ORM

Question

For example, you use some MVC framework for your web application and for most of the time you are thinking in very object oriented way, and that is why you opted to use an ORM framework in the first place.

However, when it comes to reporting. You decided to use reporting framework like BIRT, for example. BIRT does not know about your object relational mapping, it knows about your tables and raw SQL queries. It suddenly takes away all the abstraction that you've put in place. Nothing wrong with that but it feels rather disconnected (and 2005).

So the question is, why would you use any reporting framework when you can simply just use any (HTML5) templating framework out there to render your report. Assuming you don't need the multi-format exporting capabilities of a reporting framework.

Remarks: performance is not an issue ... at all

Answer 1

Working with a framework is all about trade-offs: you lose some capabilities or flexibility in one area to gain an advantage that matters to you. For example:

• Reporting tools might offer different export capabilities out-of-the-box: you can export any report to PDF or XLS or CSV or HTML or...
• Reporting tools might offer scheduling and the ability to run reports automatically at a given time
• Reporting tools might offer you advanced formatting capabilities such as sorting or templating
• Reporting tools might allow you to query different systems and join data across these systems, using different technologies (SQL vs XML vs JSON vs...)

It's not that this can't be done in a roll-your-own HTML reporting application, it's just that this takes time and effort. You should ask yourself if you want to spend time and effort writing your own reporting when there are frameworks that can take care of that for you. Just like you should ask yourself if you want to spend time and effort writing SQL and mapping your domain to the database or use an ORM.

There is also the fact that there is a big difference between your object model and the reporting model. An object model is very different from a report model and the way you write your object model does not necessarily map very well to reporting. Unless you specifically design your object model to handle reporting, chances are a report on top of this model will have SELECT N+1 issues. Reporting benefits a great deal from queries that use JOINS and the like.

Lastly, for really big applications denormalisation of data and things like data warehousing mean that you are working with a database-structure that is intended and optimized for reporting anyway. It doesn't make a lot of sense to introduce a model on top of that because SQL is very good at reading from this kind of data storage.