Approccio alla progettazione del registro

Question

Approccio alla progettazione del registro

#1 da (1 voti)
#2 da (0 voti)

4

La registrazione è sempre stata un incubo per me! Ora devo implementarlo di nuovo per un sistema proxy. In questa applicazione proxy, alcuni sistemi richiedono al sistema proxy di chiamare alcuni altri servizi. Quello che devo registrare è

Tempo richiesta
Richiedente IP
Richiedi parametri come XML
Nome servizio richiesto
Metodo di servizio richiesto
Tempo di risposta
Dati di risposta come XML
Messaggio di risposta (se si verifica un'eccezione, verrà registrato come messaggio)

Ho considerato di aggiungere due righe ai miei metodi:

// Log Request
Task.Factory.StartNew(() => Logger.Log(RequestParameters.ToXML(),Assembly.GetCallingAssembly().FullName, MethodBase.GetCurrentMethod().Name, DateTime.Now));

// Invoke requested service and get response

// Log Response
Task.Factory.StartNew(() => Logger.Log(Response.ToXML(), DateTime.Now));

Voglio anche registrare le transazioni nidificate.

Si supponga che una transazione contenga una richiesta e una risposta. Una transazione può contenere molte altre transazioni interne. Quando ricevo una richiesta, dovrei registrare una transazione e inserire una richiesta per questo, in seguito, quando la risposta ricevuta, dovrei aggiornare la risposta della transazione. Tieni presente che sto cercando di memorizzare la relazione di richiesta e risposta per un migliore monitoraggio.

Come posso aggiungere tranquillamente questa procedura di registrazione ai metodi? Voglio limitare gli sviluppatori a implementare questi sistemi di registrazione in tutti i metodi, alcune cose come l'interfaccia o l'ereditarietà per il corpo del metodo sono richieste. Posso farlo per attributi? Allora come?

design c# object-oriented-design logging

posta Reza Owliaei 13.03.2013 - 14:38

fonte

2 risposte

Leggi altre domande sui tag design c# object-oriented-design logging

Usando un DAO per astrarre il nostro ORM dal resto dell'applicazione Codeigniter / flusso di lavoro MVC

score 1 · Answer 1

Per limitare gli sviluppatori a utilizzare il meccanismo di registrazione per tutto ciò che vogliono, renderne la visibilità solo interna. Puoi quindi renderlo disponibile solo ai tuoi progetti aggiungendo l'attributo di assemblaggio InternalsVisibleTo .

Per aggiungere in modo sicuro e uniforme il meccanismo di registrazione ai metodi, implementare solo la funzionalità nei metodi e avvolgere i metodi nei delegati, un po 'come nel pseudocodice C # seguente:

internal Func<RequestParameters, Response> WrapServiceClientWithLogger(Func<RequestParameters, Response> callService)
{
    return requestParameters => {
        // Log Request
        Task.Factory.StartNew(() => Logger.Log(requestParameters.ToXML(),
            Assembly.GetCallingAssembly().FullName, GetMethodName(callService), 
            DateTime.Now));

        var response = callService(requestParameters);

        // Log Response
        Task.Factory.StartNew(() => Logger.Log(Response.ToXML(), DateTime.Now));
        return response;
    }
}

score 0 · Answer 2

Questo è lo scenario ciao mondo per Programmazione orientata all'aspetto (AOP) e io sono un ENORME fan di esso. La tua menzione / domanda sull'uso degli attributi è esattamente il dettaglio di implementazione che viene utilizzato.

Il mio preferito per .NET, anche se non è gratuito (puoi lanciare il tuo usando il reflection, e ho, ma la performance è relativamente cattiva) è PostSharp .

Essenzialmente, hai un Attributo che eredita da un attributo di aspetto PostSharp (ad esempio OnMethodBoundaryAspect ). Esegui l'override di OnEntry e OnExit per rendere le tue chiamate asincrone da tracciare.

Quello che succede è che PostSharp si inserisce nella compilazione e "tesse" il codice dal tuo aspetto all'IL che viene prodotto dal compilatore, quindi le prestazioni sono approssimativamente identiche a quelle che sarebbero se lo avessi codificato a mano nel metodo te stesso.

Nota: non ho affiliazione zero con postsharp e non ho mai avuto l'opportunità (ad es. budget) di usarlo in produzione - purtroppo. Ho usato AOP in .NET con successo però.