Aggiunta di trasformatori di stringhe di oggetti personalizzati a un campo elenco statico globale nella mia libreria di registrazione. Esiste un modo migliore?

1

Sto scrivendo una libreria di registrazione centrale. In esso è presente un attributo del metodo AutoLogAttribute che registra automaticamente la voce / uscita dei metodi e i relativi parametri (serializzati automaticamente) come segue:

[AutoLog]
public void GenerateInvoice(string customerId)
{
    ...
}

// Outputs
// af8291: Entering GenerateInvoice with parameters: { customerId: 'GZilla' }
// af8291: Exited GenerateInvoice. Ellapsed time: 480.12 ms

Il mio problema sorge quando i parametri sono POJO che serializzano su stringhe enormi.

Per impostazione predefinita, voglio semplicemente ignorare eventuali non primitivi e consentire agli utenti di specificare in che modo richiedere la serializzazione.

È importante notare che poiché la maggior parte degli oggetti sono POJO nel mio caso, non posso iniziare a richiedere l'estensione di un'interfaccia come ILoggable . Anche estendere ToString() è indesiderabile perché idealmente un oggetto dovrebbe essere ricostruibile da esso.

Stavo pensando di consentire agli utenti di aggiungere trasformatori di stringhe di oggetti personalizzati a un campo elenco statico globale in AutoLogAttribute (ad esempio, in un codice di inizializzazione della loro app). So che questa è una pessima pratica. La mia domanda è, c'è un modo migliore per risolvere il mio problema?

public class AutoLogAttribute
{
    // something like this
    public static Dictionary<Type,Func<object,string>> ParameterTransformers { get; private set; }
    ...
}


public class Program
{
    public static void Main(string[] args)
    {
        AutoLogAttribute.ParameterTransformers[Customer.Type] = (c) => c.Id;
        AutoLogAttribute.ParameterTransformers[Order.Type] = (o) => o.OrderNumber;
        ...
    }

    [AutoLog]
    public void ProcessOrder(Customer customer, Order order)
    {
        ...
    }
}
    
posta makhdumi 25.07.2016 - 23:29
fonte

1 risposta

1

Se vuoi che qualcosa influenzi l'applicazione a livello globale, in pratica dovrai utilizzare le variabili globali / statiche.

Le cattive pratiche non sono dogmi a cui devi aderire religiosamente (vedi anche programmazione setta cargo ). Dovresti capire il motivo per cui sono cattivi e valutare se tali motivi si applicano alla tua situazione o in che modo puoi attenuarli.

Uno dei motivi per cui lo stato globale è negativo è che può essere modificato da qualsiasi punto di un programma, rendendo difficile capire cosa sta succedendo. Non penso che questo sia un grosso problema qui, dato che lo stato globale sarà probabilmente impostato una volta e non sarà mai modificato.

Ci sono altri motivi per cui lo stato globale è cattivo (rende i test unitari più difficili, ha problemi con i programmi multi-thread), dovresti capirli e pesare se sono rilevanti nel tuo caso e se lo sono, come gestirli .

    
risposta data 28.07.2016 - 15:25
fonte

Leggi altre domande sui tag