Best practice / pattern per generare report PDF

Naviga le tue risposte
1

Ho una funzione di generazione di PDF nella mia app. Sto usando iTextPDF per generare report, quindi funziona bene. Il problema non è esattamente nella generazione di PDF ma nell'approccio. Attualmente il codice di generazione PDF sembra orribile, hardcoded e non flessibile, quindi c'è molta duplicazione e tutto è altamente accoppiato.

Esistono pratiche migliori o comuni per tale compito? Forse qualche approccio o schema architettonico? Sarei molto grato per qualsiasi consiglio e esempio di codice che fosse dimostrato affidabile e flessibile.

    
posta CROSP 21.04.2016 - 13:32
fonte

1 risposta

6

Se desideri solo una versione PDF del tuo rapporto, è sufficiente applicare semplicemente buone pratiche di factoring. Scrivi funzioni di utilità, estrai codice comune in subroutine, scegli nomi di metodi validi e dopo un po 'avrai un generatore di rapporti gestibile abbastanza buono.

Tuttavia , il secondo sembra che dovrai supportare qualsiasi altro formato di output rispetto al PDF per lo stesso rapporto (ad es. testo, e-mail HTML, qualunque sia) , immediatamente rifatta il tuo codice in un generatore (decide quali informazioni stampare e in quale ordine) e un renderer (sa come produrre output in grassetto, centrato o doppio spaziatura).

Quindi, ogni volta che il contenuto del report cambia, devi solo aggiornare il generatore e ogni volta che cambiano i requisiti di stile, devi solo aggiornare una piccola parte dei tuoi renderer. E quando è richiesto un altro formato di output, è sufficiente aggiungere un'altra sottoclasse di renderer piuttosto che passare di nuovo attraverso l'intera codebase.

    
risposta data 21.04.2016 - 13:39
fonte

Leggi altre domande sui tag

Sono state create nuove interfacce di marker Java vuote per soddisfare un contratto di metodo esistente con un odore di codice? Git: come testare il codice locale prima del commit