Segnalazione e codifica - pensieri?

Question

Recentemente ho avuto un progetto in cui dovevo ottenere alcuni dati da un particolare sistema software a un portlet. Il software usava un database, e ho passato un bel po 'di tempo a modellare i dati che volevo e quindi creare un servizio web in modo che il mio portlet potesse afferrare le informazioni.

Poi improvvisamente mi ha colpito che stavo sprecando il mio tempo. Ho afferrato BIRT, l'ho gettato in un portlet e poi ho appena scritto alcuni rapporti che hanno afferrato direttamente i dati necessari dal database. Avevo finito in un pomeriggio.

Capisco che la segnalazione è una strada a senso unico, ma questo mi ha fatto riflettere. Gli strumenti di reporting possono essere molto efficaci per creare report (duh) dai tuoi dati reali, ma quando lo fai, stai bypassando il tuo modello che, tranne nei casi semplici, non è una rappresentazione diretta dei tuoi dati così come esiste nel tuo database.

Se si sta scrivendo un'applicazione ad alta intensità di dati e si richiede la possibilità di eseguire report non banali, si ignora l'applicazione e si utilizza qualcosa come BIRT o Crystal Reports? Come gestisci questi strumenti come parte del tuo processo generale? Ritieni che i rapporti che scrivi siano parte della tua domanda e li tratti come tali? Un rapporto è una vista, un modello e un controllore (se vuoi) tutto in un unico grande pasticcio, come gestisci e interpreti e pianifichi per quello?

Domanda riveduta: è possibile e anche comune che un report esegua alcuni calcoli aziendali che in un mondo perfetto si desidera siano contenuti nella propria applicazione. Ciò può portare a una mancata corrispondenza delle informazioni restituite all'utente. D'altra parte, gli strumenti di reporting rendono così facile raccogliere e visualizzare informazioni che è difficile adottare l'approccio di un purista e fare tutto dall'interno dell'applicazione. Esistono buone tecniche per garantire che i dati nei report corrispondano ai dati che potrebbero essere visualizzati nella GUI normale?

Answer 1

I report fanno parte della tua app ma, dato che generalmente sono qualcosa su cui un utente ha idee forti rispetto alla tua interfaccia utente di acquisizione dei dati, sacrificherei la purezza per comodità/velocità di consegna e tornare a "reale" codifica ... :-)

Non appena hai eseguito un rapporto, gli utenti ne vogliono un altro o cambiano il colore o il raggruppamento facoltativo o altro filtro o ... qualcosa che ti porta lontano da cose più eccentriche ... quindi non distruggo l'intestino mantenendo la purezza.

Answer 2

La segnalazione è fondamentale. Il reporting è principalmente cruciale per condividere i valori raccolti in un sistema con utenti esterni, ad es. utenti che non utilizzano direttamente il sistema (ad es. gestione per dati di vendita). Quindi il reporting è molto più di una semplice visualizzazione di fatti e cifre ed è un elemento centrale in quasi tutti i sistemi che guidano uno spot pubblicitario.

Almeno i sistemi più avanzati consentono di migliorarli: con i propri "controlli" riutilizzabili. Anche una via di ritorno può essere implementata - se si utilizzano solo i plugin corretti. Una volta ho scritto un sistema per inviare e-mail da un report, perché il sistema non consentiva il cambiamento. Ha funzionato, anche se non era destinato a essere utilizzato in questo modo;)

I report rappresentano una buona parte dell'applicazione e ottieni molta libertà se rendi i rapporti modificabili per i tuoi clienti. A volte ti vengono proposte più possibilità di quante pensavi quando hai costruito il sistema in primo luogo.

Quindi sì, per me il reporting fa parte del sistema.

Answer 3

Questa è davvero una linea sottile. Non si vuole perdere troppo tempo a costruire report (che gli utenti vogliono comunque modificare in qualsiasi momento) ma non si vuole duplicare la logica inserendo la logica di business nei report!Con i nostri prodotti di reporting su Data Dynamimcs penso che abbiamo raggiunto un mezzo felice tra questi due tradeoff.

Utilizzando ObjectDataProvider (vedere i collegamenti di seguito per ulteriori informazioni) è possibile associare il report direttamente agli oggetti business (semplici vecchi oggetti) in modo da non dover ignorare il livello aziendale per ottenere i dati. Allo stesso tempo, forniamo un modo per fare riferimento e utilizzare le funzioni di altre librerie nel vostro rapporto. In questo modo se si dispone già di un codice configurato per eseguire alcuni calcoli della logica aziendale, è possibile riutilizzare tali funzioni direttamente all'interno del report. Puoi vedere un esempio di questo anche nei link sottostanti.

• Associazione a oggetti per i dati (vedere la sezione "Oggetto Provider"): http://www.datadynamics.com/Help/ddReports/ddrconDataSetAndObjectDataSource.html
• Aggiunta di codice personalizzato per i report Procedura dettagliata: http://www.datadynamics.com/Help/ddReports/ddrwlkCustomCode.html
• Utilizzando assembly personalizzati (riferimento a librerie condivise/DLL dal vostro rapporto) : http://www.datadynamics.com/Help/ddReports/ddrconCustomCode.html e http://www.datadynamics.com/Help/ddReports/ddrtskCreatingAnInstanceMethod.html

Scott Willeke

dati Dynamics/GrapeCity

Answer 4

Il modo in cui ho sempre lavorato con i report consiste nel considerare i report delle parti come parte del code-base e memorizzati nella sorgente insieme all'applicazione. In alcuni contesti, i report sono più importanti dell'applicazione, in quanto la gestione prende le decisioni aziendali fuori dai dati dei report, avendo le informazioni errate può causare loro di cancellare una linea di prodotti, annullare una campagna o licenziare una persona di vendita. Ovviamente, questo dipende molto dalla tua gestione e dalla tua applicazione.

Per quanto riguarda la coerenza del modello, questa è una domanda un po 'più complicata. Un modo per garantire un modello coerente tra i report e l'applicazione è utilizzare le stored procedure (o le viste) per recuperare i dati, a seconda dell'architettura dell'applicazione.

Answer 5

Vedo segnalare semplicemente un'altra visualizzazione dei dati, non una vista/modello/controller in uno (beh, forse una vista e un controller in uno).

Abbiamo i nostri rapporti (servizi di reporting sql 2008 incorporati) che utilizzano un servizio nel nostro livello di applicazione per ottenere dati (in linea con il nostro standard, che l'accesso ai dati è in un repository). Queste funzioni potrebbero eseguire una query semplice o gestire un'elaborazione molto complessa che sarebbe un incubo nell'ambiente di reporting o una stored procedure. In pratica, riteniamo che questo non richieda più la codifica di una procedura memorizzata una tantum che, man mano che il sistema cresce e cresce, diventa un incubo da mantenere.

Trattare un report come una tantum o non integrarlo nella progettazione dell'applicazione è un grosso errore.