where would report generation code go . .

Question

I have a visual studio solution with the following projects:

1. UI
2. DataAccess
3. BusiessLogic
4. BusinessObjects

I now have a bunch of code that generates reports that are sent out via email or saved as csv files.

These ReportGenerators classes take in business objects and output either files or strings.

which project would you put them in? I am leaning toward an answer but wanted to see what others thought?

Answer 1

I would create a separate reporting project. It doesn't belong in the UI (I assume they run in the background) - it is effectively a 'reporting logic' layer.

If you think about how you might want to support reportng, you may want a backend service but you might want to expose the data via a web service as well in the future. If you need to provide users a front-end reporting facility you plug into the reporting logic as you would a normal UI -> Logic -> Data Access architecture.

Also, if you separate your reporting code out you are then free to extract it to a dedicated reporting tier in the future.

Answer 2

A agree with manwood's post - you should build them as reports (put a sproc behind the reports if necessary) for the following reasons:

• You can run the reports and display them through the ReportViewer control. This is fairly straightforward to do.

• You (and more importantly other people supporting the application) can extend the application with more reports without having to release another build of the application. This is quite a useful feature if you don't want to be tied to supporting the application.

• You can publish the reports through reporting services as well.

• You get all the data export options of reporting services (Excel, csv, pdf etc.) with the Reporting Services framework.