Clever Geek Handbook

Where the generation code will be reported.

I have a visual studio solution with the following projects:

  • interface
  • DataAccess
  • BusiessLogic
  • BusinessObjects

Now I have a bunch of code that generates reports that are emailed or saved as csv files.

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

in which project would you introduce them? I'm leaning towards the answer, but wanted to see what others think?

+1


source to share


2 answers


I would create a separate reporting project. It does not belong to the UI (I assume they are running in the background) - it is actually the "reporting logic layer".

If you are thinking about how you might need report support, you might need a backend service, but you might also want to view the data through a web service in the future. If you need to provide users with an interface for presenting reports, you connect to the reporting logic like a regular UI -> Logic -> Data Access Architecture.



Also, if you separate your report code, you can extract it to a dedicated reporting layer in the future.

+2


source


Agree with the manwood mail - you should create them as reports (if necessary, include sproc behind messages if necessary) for the following reasons:



  • You can run reports and display them through the ReportViewer control. This is fair and simple.

  • You (and more importantly, other people supporting the application) can extend the reporting application without having to release another assembly of the application. This is a pretty useful feature if you don't want to be tied to application support.

  • You can publish reports through reporting services.

  • You get all the export options for Reporting Services data (Excel, csv, pdf, etc.) with Reporting Services Structure.

0


source






More articles:


All Articles