I've pondered over this in my brain quite alot about your typical n-Layer solution that contains your busienss logic in your business object classes. We take this logic (logic used for calculations, decisions on data to display/use, etc) out of database views and into the business object itself. This works great for your application and provides excellent flexibility, but my biggest concern has always been with reporting on this data.

Most reporting tools I have used will connect to a database view, but not to a collection of .NET business object classes in order to display the right data on a report, chart, etc...

How would you still make the argument for the use of business objects containing your logic in this scenario?

Points

You might have to **duplicate your logic **in the view or report to get the right info on the report... You could **OLAP **the data from the business object to a database for reporting... Use **SQL Reporting Services in client mode **to report directly off of your business object classes...

I am looking for other's people opinions about this. What has been tried? What is used? What works? What doesn't work so well? etc.....

Thanks!

Dan

Here is other people's thoughts about that: http://llblgen.com/TinyForum/Messages.aspx?ThreadID=9104 http://llblgen.com/TinyForum/Messages.aspx?ThreadID=2104 http://llblgen.com/TinyForum/Messages.aspx?ThreadID=5689

Hello, We bought devExpress XtraReport and tried to do some reporting using that tool and our business layer but reports were slow, not very flexible and required tons of coding. A nightmare to maintain, especially because all our customers were asking for different charts and analysises based on their own respective business.

Because most of the reports data couldn't be extracted using simple aggregate queries and joins, we ended up executing queries in loops for retrieving pieces of information which weren't available as it. For example, knowing which was the buyPrice of a Product at the time it was sold required us to check the product history table using a specific query. I suppose you guess how fun it became when we had to work on 400'000 sales facts.

The solution was to create a separate database with a star schema updated on a daily basis. Most of our reports are now easy done using a single query, hand-coding is almost inexistent, and speed is no longer a problem. Even if you don't have the power of an OLAP engine, it's worth the effort.

Hope this helps.