Pourquoi les enregistreurs recommandent-ils d'utiliser un enregistreur par classe?

Question

Selon la documentation de NLog:

La plupart des applications utilisent un enregistreur par classe, son nom étant identique à celui de la classe.

C'est la même manière que log4net fonctionne. Pourquoi est-ce une bonne pratique?

Answer 1

Avec log4net, à l'aide d'un enregistreur par classe permet de capturer facilement la source du message de log (ie. la classe d'écriture dans le journal). Si vous n'avez pas un logger par classe, mais plutôt un enregistreur pour l'ensemble de l'application, vous avez besoin de recourir à davantage de réflexion des trucs pour savoir où le journal des messages.

Comparer les suivantes:

Journal par classe

using System.Reflection;
private static readonly ILog _logger = 
    LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);    

public void SomeMethod()
{
    _logger.DebugFormat("File not found: {0}", _filename);
}

Un logger par application (ou similaire)

Logger.DebugFormat("File not found: {0}", _filename); // Logger determines caller

-- or --

Logger.DebugFormat(this, "File not found: {0}", _filename); // Pass in the caller

En utilisant le second exemple, l'Enregistreur de données serait nécessaire de construire une trace de la pile pour voir qui était de l'appeler ou de votre code devrait toujours se passer en l'appelant. Avec l'enregistreur de données-par classe de style, vous avez encore le faire, mais vous pouvez le faire une fois par classe au lieu d'une fois par appel et d'éliminer un grave problème de performance.

Answer 2

Avantage pour l'utilisation de "logger par fichier" dans NLog: vous avez la possibilité de gérer/filtre journaux par espace de noms et le nom de la classe. Exemple:

<logger name="A.NameSpace.MyClass"      minlevel="Debug" writeTo="ImportandLogs" /> 
<logger name="A.NameSpace.MyOtherClass" minlevel="Trace" writeTo="ImportandLogs" /> 
<logger name="StupidLibrary.*"          minlevel="Error" writeTo="StupidLibraryLogs" />

<!-- Hide other messages from StupidLibrary -->
<logger name="StupidLibrary.*" final="true" /> 

<!-- Log all but hidden messages -->
<logger name="*" writeTo="AllLogs" /> 

NLogger est très utile extrait de code pour ce faire. nlogger extrait de créer de code suivant:

private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();

Si seulement quelques clics et vous avez logger par classe. Il va utiliser l'espace de noms et le nom de classe comme le nom de l'enregistreur. Pour définir les différents nom de votre classe logger vous pouvez utiliser ceci:

private static NLog.Logger logger = NLog.LogManager.GetLogger("MyLib.MyName");

Et comme @JeremyWiebe dit que vous n'avez pas à utiliser des astuces pour obtenir le nom de la classe qui tente de se connecter message: Nom de l'enregistreur de données (ce qui est généralement le nom de la classe) peut être facilement connecté à un fichier (ou autres) à l'aide de ${logger} dans la mise en page.

Answer 3

Je peux voir quelques raisons pour ce choix.

• Vous saurez toujours d'où provient une instruction de journal particulière, si vous incluez le nom de l'enregistreur dans votre format de sortie de journal.
• Vous pouvez contrôler les instructions de journal que vous voyez à un niveau de grain fin en activant ou désactivant certains enregistreurs ou en définissant leur niveau.

Answer 4

Dans la plupart des cas, le nom de la classe fournit un bon nom pour le consignateur. Lors de l'analyse des fichiers journaux, vous pouvez voir le message de journal et l'associer directement à une ligne de code.

Les journaux SQL d'Hibernate constituent un bon exemple de ce qui n'est pas la meilleure approche. Il existe un enregistreur partagé nommé "Hibernate.SQL" ou quelque chose du genre, dans lequel un certain nombre de classes différentes écrivent du SQL brut dans une seule catégorie d'enregistreur.

Answer 5

Deux raisons viennent immédiatement à l’esprit:

1. Avoir un journal séparé pour chaque classe facilite le regroupement de tous les messages / erreurs de journal relatifs à une classe donnée.
2. Avoir un journal dans une classe vous permet de consigner des détails internes qui peuvent ne pas être accessibles en dehors de la classe (par exemple, un état privé, des informations relatives à la mise en œuvre d'une classe, etc.).