In der log4net-Dokumentation erfahren Sie, wie Sie Ihre benutzerdefinierten Daten in einer Datei protokollieren können. Wenn dies der Fall ist, sollten Sie in der Lage sein, dieselben Daten in der Datenbank zu protokollieren. Fügen Sie einfach weitere Spalten in Ihrer Tabelle, mehr Spalten im Knoten <command text> des AdoNetAppender und weitere <parameter> Knoten hinzu.
Ich denke, dass Sie etwas Arbeit haben werden, um Ihre eingehenden und ausgehenden Parameter zu protokollieren. Brauchen Sie sie in separaten Spalten angemeldet (wahrscheinlich nicht einfach sauber zu tun)? Ist es in Ordnung, wenn sie zusammen mit der Nachricht protokolliert werden?
Zum Beispiel, wenn Sie die folgende Methode, die Sie setzen in der Anmeldung werden soll:
public void DoSomething(int x, int y)
{
log.Info("Inside DoSomething");
}
Was wollen Sie Ihre Ausgabe aussehen? Möchten Sie, dass die "Standard" log4net-Informationen in separaten Spalten (Zeitstempel, Loggername, Level, Nachricht) erscheinen? Was ist mit den Parametern? Sollte x und y erscheinen in separaten Spalten (wahrscheinlich nicht sehr einfach zu tun, es sei denn jede Methode die gleiche Anzahl von Parametern) oder wäre es in Ordnung, wenn die Parameter wie folgt protokolliert wurden:
public void DoSomething(int x, int y)
{
ILog log = LogManager.GetLogger("abc");
log.InfoFormat("Parameters: x = {0}, y = {1}", x, y);
log.Info("Inside DoSomething");
}
Die Log-Anweisungen werden Meldungen erzeugen das wird ungefähr so aussehen:
11/29/2010 16:36:00 | abc | INFO | Parameters: x = 10, y = 20
11/29/2010 16:36:00 | abc | INFO | Inside DoSomething
Ich habe die | verwendet Zeichen, um zu zeigen, wie die Felder mit einem Musterlayout aussehen würden, das den Zeitstempel, den Protokollierernamen, die Protokollebene und die Nachricht anzeigt. Wenn Sie eine AOP-Lösung wie PostSharp betrachten, kann Ihnen das helfen, weil Sie relativ einfach Enter/Exit-Logging hinzufügen können, ohne Ihren Anwendungsquellcode mit Logging-Anweisungen zu "verschmutzen". Innerhalb des Logging-Aspekts hätten Sie Zugriff auf die Parameter der Methode.
Ich könnte etwas fehlen, aber ich vermute, dass wenn Sie Ihre Methode Parameter als einzelne Spalten in der Datenbank pflegen wollen, dann werden Sie es schwer zu tun finden. Wenn Sie damit zufrieden sind, alle Parameter (manuell) für jede Methode als eine einzelne Spalte (im Wesentlichen eine formatierte Zeichenfolge) zu kombinieren, wird das einfacher.Ein Preis, den Sie zahlen müssen, ist, dass Sie alle Parameter explizit protokollieren müssen (es sei denn, Sie gehen auf die AOP-Route).
Wenn Sie log4net verwenden, sollten Sie auch NLog verwenden. Es wird Ihnen nicht unbedingt bei den oben beschriebenen Problemen helfen, aber ich denke, dass es ein würdiger Konkurrent für log4net ist.
[EDIT]
Um die „Komponentennamen“ von log4net protokolliert zu erhalten, sollten Sie Ihre Loggern für Ihre Komponenten nennen. Wenn Sie LogManager.GetLogger (Name) aufrufen, können Sie einen beliebigen Namen (oder Typ) übergeben. Ein übliches Muster ist in jeder Klasse Code wie diese hat:
public class MyClass
{
private static readonly ILog logger = LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
public void DoSomething(int x)
{
logger.InfoFormat("Inside DoSomething. x = {0}", x);
}
}
Dies wird einen Logger mit den vollständig qualifizierten Klassennamen (Namespace + Klassenname) genannt bekommen. Wenn Sie dies in jeder Klasse tun, können Sie die Protokollierung (Ebene, Appender usw.) pro Klasse steuern. So können Sie die Protokollierung für Class1 problemlos in Info umwandeln und für Class2 Off usw. protokollieren. Dies gibt Ihnen das Potenzial für die größtmögliche Kontrolle Ihrer Protokollierung.
Nun sind Sie in Ihrer Konfigurationsdatei nicht verpflichtet, jeden Logger (d. H. Jeden vollständig qualifizierten Klassennamen) explizit aufzuführen. Sie könnten einfach den Root-Logger konfigurieren, und dann würden diese Einstellungen auf jeden Logger angewendet werden. Sie können die Protokollierung nach Namespace steuern. Zum Beispiel, wenn Sie für CompanyX arbeiten und Sie explizite Namespace Regeln haben, Ihre Namespaces aussehen könnte:
CompanyX
CompanyX.DataAccess
CompanyX.DataAccess.Read
CompanyX.DataAccess.Write
CompanyX.GUI
CompanyX.Forms
CompanyX.Controls
Innerhalb jeder Namespace, können Sie verschiedene Klasse (wie verschiedene Datenleser, Hilfsklassen, Daten Autoren, etc). Wenn Ihre Klassen wie folgt organisiert sind und Ihre Klassen Logger wie oben erhalten, können Sie die Protokollierung für alle Klassen in CompanyX oder alle Logger in CompanyX.DataAccess oder CompanyX.DataAccess.Read usw. problemlos konfigurieren. Sie können sogar die gesamte Abmeldung deaktivieren , aber schalte es für diese problematische Klasse ein, die dir Probleme bereitet.
Sie können Ihre Logger auch mit beliebigen Namen versehen (d. H. Sie müssen den Klassennamen nicht verwenden, wenn Sie nicht möchten). Sie könnten Funktionsbereiche in Ihren App (s) definieren und Logger basierend darauf erhalten:
Und so weiter. Ich sehe nicht, dass dies einen großen Vorteil gegenüber der Verwendung des vollständig qualifizierten Klassennamens bietet. Wenn Ihre Namespaces gut organisiert sind, haben Sie die Möglichkeit, Ihre Protokollierung zu konfigurieren, um maximale Flexibilität bei minimalem Aufwand zu erreichen. Ein anderes Wort auf NLog ... NLog ist sehr ähnlich zu log4net. Es hat die nützliche Funktion in der Lage, automatisch einen Logger für die aktuelle Klasse zurück:
Logger logger = NLog.LogManager.GetCurrentClassLogger();
Das zumindest eine gewisse Eingabe auf Ihrer Seite speichert. NLog hat gerade ein neues Release herausgebracht (derzeit in der Betaversion).
Ich weiß nicht, ob das alles geholfen hat, aber ich hoffe es hat es getan!
Viel Glück!
Es ist in Ordnung, alle Parameter in 1 Feld zu haben, aber (wie ich im Kommentar zu einer anderen Antwort erwähnt habe) möchte ich Komponentenname in einer separaten Spalte haben (ohne den globalen Kontext für jeden Anruf zu ändern). Außerdem möchte ich 3 zusätzliche Spalten haben: income_data, outcome_data, error_message. Wahrscheinlich könnte ich einige verschiedene Logger-Instanzen konfigurieren (1 pro Komponente)? Und in diesem Fall muss ich nicht jedes Mal die globalen Einstellungen ändern. Entschuldigung, ich bin neu bei log4net. – Budda
Ja, wahrscheinlich möchten Sie mindestens einen Logger pro Komponente haben. Ich habe einige Beispiele in meiner Antwort hinzugefügt. – wageoghe