Quale design proporresti per registrare i dati dei rapporti in modo che l'acquisizione di, ad esempio, un campo modulo aggiuntivo possa essere implementata più facilmente?

Gran parte di questo dipende dalla tecnologia e dalla soluzione, ma ho usato diversi strumenti che sicuramente non la penso in questo modo.

Se stai facendo web usando qualcosa con un modello di eventi, un concetto di un ciclo di vita di richiesta / risposta puoi facilmente fare tutto il tuo logging agganciando l'evento di eccezione e agganciando l'evento di risposta completato, mantenendo solo una collezione di cose loggabili attraverso il ciclo di vita.

Se stai facendo un'app desktop, le cose diventano un po 'più varie. Di solito ci sono ancora alcuni eventi comuni da agganciare, ma altre volte è necessario chiamare esplicitamente il logger perché il salvataggio di tutto alla fine del ciclo di vita si disfarebbe rapidamente.

In .Net è possibile risolvere molto implementando un listener di traccia personalizzato, in questo modo è possibile utilizzare il riferimento di traccia predefinito, ma ottenere comunque dati che non sembrano terribili durante la revisione.

Per quanto riguarda l'accesso a un db separato o no, dipende da molte cose, ad esempio se il log deve essere un'origine di verifica valida e chi può accedere ai dati e se si sta tentando di registrare i problemi di connessione a database: -)

Se ho bisogno di cercare il log in modo efficiente non immagazzino i messaggi come grandi blob, ma a volte creo i messaggi come un blob e li divido nel formato finale in un processo separato. Quello che fai per ottenere il messaggio in primo luogo dipenderà interamente da ciò che stai facendo. Ho alcune app in cui il sovraccarico di serializzazione degli oggetti è semplicemente eccessivo per il logging in corso, per non avere un impatto perfetto, per non parlare del fatto che avrei esaurito lo spazio di archiviazione in poche ore. La maggior parte di quelli registro solo le stringhe ID. Altre app hanno oggetti che desidero registrare come oggetti serializzati, ma l'oggetto non è serializzabile, per quelli è possibile utilizzare un formattatore personalizzato o un intermedio. Altre volte ho il lusso di oggetti a bassa velocità e serializzabili, quindi uso solo i serializzatori di default.

Un po 'di consigli, se hai intenzione di rendere sicuro il logging infinitamente estensibile hai un modo per limitarlo / ridurlo

Dipende dalla tecnologia in uso.

Probabilmente userò un contenitore di iniezione delle dipendenze e un'interfaccia chiaramente definita per il logger per gestire questa preoccupazione trasversale. È quindi possibile iniettare il servizio di registrazione nel punto in cui è necessario.

Se il logger ha bisogno di catturare un nuovo campo in una classe, probabilmente lo faremo usando annotazioni / attributi, in modo da avere un singolo punto di cambiamento quando è necessario estendere la struttura dati. Il logger si limita a cercare questi attributi / annotazioni quando si registra un oggetto dati e si reagisce di conseguenza. È inoltre possibile incapsulare la logica di registrazione complessa in quegli attributi / annotazioni. Funziona molto bene quando ti colleghi agli oggetti.

Esempio in C #:

public class Customer
{
    [LogData]
    public string Name
    {
        get;
        set;
    }

    [LogData]
    public string FirstName
    {
        get;
        set;
    }
}

o

[LogData] //dumps all fields of the class to the log
public class Customer
{
    /*.../*
}

Tuttavia, quando si vincolano i campi a un set di dati o qualcosa di simile, è necessario un approccio diverso. Creo quindi un logger che semplicemente scarica tutte le colonne del set di dati per impostazione predefinita. Poiché tali set di dati consistono principalmente di codice generato automaticamente, è difficile infastidirli, ma è possibile legare il tipo di set di dati a una configurazione in cui sono specificati i campi da registrare se è necessario essere più precisi sui dati scaricati, risultante in un singolo punto di cambiamento e anche quando è necessario estendere la registrazione.

Conserverei le informazioni di registrazione in una singola colonna di contenuto (insieme ad altre informazioni), probabilmente come XML. Qui lo spazio non è preoccupante, dato che oggi è molto economico e il sovraccarico dell'elaborazione XML è trascurabile. Se è necessario disporre dell'accesso diretto al database a tutti i campi di dati registrati, non sarà possibile creare un campo separato per ogni campo logico aziendale nell'applicazione, il che significa che sarà necessario estendere il database. Probabilmente potresti sempre clonare il database originale e quindi accedere a questo database di registrazione in uno schema di database completamente nuovo. Un ORM potrebbe quindi semplicemente passare lo schema e mantenere gli oggetti registrati abbastanza facilmente, se si sta utilizzando un ORM, cioè.

Implementa qualcosa sulla natura di ActiveRecord . Questo è stato fatto in un certo numero di lingue. Allo stesso modo, progetta lo stesso concetto "attivo" in qualsiasi parte del tuo lavoro che necessiti della funzionalità (ad esempio qualcosa come "ActiveForms")

Fondamentalmente il minimo di ciò che vuoi è

A) Rileva le modifiche in un set di dati (campi modulo)

• Conserva un archivio della struttura della versione nota corrente
• Confronta CurrentStructure a LastKnownStructure . Se diverso allora, ..

B) Attiva gli aggiornamenti dinamici

• Consenti a un oggetto, a un database o altro metodo di memorizzare un elenco (definito anche dinamicamente) di rapporti / sezioni di rapporti / ecc. che si riferiscono ai dati.
• Passa in rassegna l'elenco e aggiorna i batch o fai in modo che ogni elemento nell'elenco controlli l'oggetto del set di dati per un flag di aggiornamento.
• In base al contesto, aggiorna o continua il codice

Solo una nota, potresti semplicemente attivare l'aggiornamento completo alla generazione del rapporto (al contrario di sulle modifiche ai campi ) Se ci sono molti cambiamenti in corso tutto il tempo, potresti risparmiare una buona quantità di costi generali . Se lo fai, potrebbe esserci bisogno di una sorta di topologia gerarchica ... un metodo significativo, sensibile al contesto, per attraversare i set di dati e controllare le modifiche.