Selon la documentation de NLog:

La plupart des applications utilisent un enregistreur par classe, où le nom de l'enregistreur est le même que le nom de la classe.

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

Avec log4net, l'utilisation d'un enregistreur par classe facilite la capture de la source du message du journal (c'est-à-dire la classe qui écrit dans le journal). Si vous n'avez pas un enregistreur par classe, mais que vous en avez un pour l'ensemble de l'application, vous devez recourir à d'autres astuces de réflexion pour savoir d'où proviennent les messages du journal.

Comparez ce qui suit:

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 enregistreur 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 deuxième exemple, le Logger aurait besoin de créer une trace de pile pour voir qui l'appelait ou votre code devrait toujours passer l'appelant. Avec le style enregistreur par classe, vous faites toujours cela, mais vous pouvez le faire une fois par classe au lieu d'une fois par appel et éliminer un grave problème de performances.

Avantage d'utiliser "logger per file" dans NLog: vous avez la possibilité de gérer / filtrer les logs par namespace et par nom de classe. Exemple:

<logger name="A.NameSpace.MyClass"      minlevel="Debug" writeTo="ImportantLogs" /> 
<logger name="A.NameSpace.MyOtherClass" minlevel="Trace" writeTo="ImportantLogs" /> 
<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 a un extrait de code très utile pour ce faire. L' nloggerextrait créera le code suivant:

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

Donc, seulement quelques touches et vous avez un enregistreur par classe. Il utilisera l'espace de noms et le nom de classe comme nom de l'enregistreur. Pour définir un nom différent pour votre enregistreur de classe, vous pouvez utiliser ceci:

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

Et, comme @JeremyWiebe l'a dit, vous n'avez pas besoin d'utiliser des astuces pour obtenir le nom de la classe qui essaie de consigner un message: le nom de l'enregistreur (qui est généralement le nom de la classe) peut être facilement consigné dans un fichier (ou autre cible) en utilisant ${logger}dans la mise en page.

Je vois quelques raisons à 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 précis en activant ou désactivant certains enregistreurs ou en définissant leur niveau.

Il existe également un avantage en termes de performances dans le cas de NLog. La plupart des utilisateurs utiliseront

Logger logger = LogManager.GetCurrentClassLogger()

La recherche de la classe actuelle à partir de la trace de pile nécessite des performances (mais pas beaucoup).

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

Les journaux SQL d'Hibernate sont un bon exemple où ce n'est pas la meilleure approche. Il existe un enregistreur partagé nommé "Hibernate.SQL" ou quelque chose comme ça, où un certain nombre de classes différentes écrivent du SQL brut dans une seule catégorie de journaliseur.

Du point de vue du développement, c'est plus simple si vous n'avez pas à créer un objet de journalisation à chaque fois. D'un autre côté, si vous ne le faites pas, mais que vous le créez de manière dynamique en utilisant la réflexion, cela ralentira les performances. Pour résoudre ce problème, vous pouvez utiliser le code suivant qui crée le journal de manière dynamique de manière asynchrone:

using NLog;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace WinForms
{
    class log
    {

        public static async void Log(int severity, string message)
        {
            await Task.Run(() => LogIt(severity, message));
        }

        private static void LogIt(int severity, string message)
        {
            StackTrace st = new StackTrace();
            StackFrame x = st.GetFrame(2);     //the third one goes back to the original caller
            Type t = x.GetMethod().DeclaringType;
            Logger theLogger = LogManager.GetLogger(t.FullName);

            //https://github.com/NLog/NLog/wiki/Log-levels
            string[] levels = { "Off", "Trace", "Debug", "Info", "Warn", "Error", "Fatal" };
            int level = Math.Min(levels.Length, severity);
            theLogger.Log(LogLevel.FromOrdinal(level), message);

        }
    }
}

Deux raisons me viennent immédiatement à l'esprit:

1. Le fait d'avoir un journal séparé pour chaque classe facilite le regroupement de tous les messages / erreurs du 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, l'état privé, les informations concernant l'implémentation d'une classe, etc.).

Probablement parce que vous voulez pouvoir enregistrer des méthodes qui ne sont visibles que par la classe sans interrompre l'encapsulation, cela facilite également l'utilisation de la classe dans une autre application sans interrompre la fonctionnalité de journalisation.

Facilite la configuration des appenders par espace de noms ou classe.

Si vous utilisez NLOG, vous pouvez spécifier le site d'appel dans la configuration, cela enregistrera le nom de la classe et la méthode où se trouvait l'instruction de journalisation.

<property name="CallSite" value="${callsite}" />

Vous pouvez ensuite utiliser une constante pour le nom de votre enregistreur ou le nom de l'assemblage.

Clause de non-responsabilité: je ne sais pas comment NLOG recueille ces informations, je suppose que cela serait une réflexion, vous devrez peut-être considérer les performances. Il y a quelques problèmes avec les méthodes Async si vous n'utilisez pas NLOG v4.4 ou version ultérieure.