dove andrebbe segnalato il codice di generazione.

Question

Ho una soluzione di Visual Studio con i seguenti progetti:

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

Ora ho un sacco di codice che genera report che vengono inviati via e-mail o salvati come file CSV.

Queste classi ReportGenerators accettano oggetti business e producono file o stringhe.

in quale progetto li metteresti? Mi sto inclinando verso una risposta, ma volevo vedere cosa pensavano gli altri?

Answer 1

Vorrei creare un progetto di reporting separato. Non appartiene all'interfaccia utente (suppongo che vengano eseguiti in background) - è effettivamente un livello di "logica di reporting".

Se pensi a come potresti voler supportare reportng, potresti desiderare un servizio back-end ma potresti voler esporre i dati tramite un servizio web anche in futuro. Se devi fornire agli utenti una funzionalità di reporting front-end, inserisci la logica dei rapporti come faresti con una normale interfaccia utente - > Logica - > Architettura di accesso ai dati.

Inoltre, se separi il tuo codice di segnalazione, sei libero di estrarlo in un livello di segnalazione dedicato in futuro.

Answer 2

Concorda con il post di manwood: dovresti crearli come rapporti (metti uno sproc dietro i rapporti se necessario) per i seguenti motivi:

• È possibile eseguire i report e visualizzarli tramite il ReportViewer controllo. Questo è abbastanza semplice da fare.

• Tu (e soprattutto altre persone supportare l'applicazione) can estendere l'applicazione con altro rapporti senza dover rilasciare un'altra build dell'applicazione. Questa è una funzione abbastanza utile se non vuoi essere legato al supporto dell'applicazione.

• È possibile pubblicare i report tramite servizi di segnalazione pure.

• Ottieni tutte le opzioni di esportazione dei dati dei servizi di segnalazione (Excel, CSV, pdf ecc.) con la segnalazione Framework dei servizi.