Ventaja para usar "logger per file" en NLog: tiene la posibilidad de administrar/filtrar registros por espacio de nombres y nombre de clase. Ejemplo:

<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 tiene un fragmento de código muy útil para hacer esto. El fragmento nlogger creará el siguiente código:

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

Así que solo unas pocas pulsaciones de teclado y tienes logger por clase. Utilizará el espacio de nombres y el nombre de la clase como el nombre del registrador. Para establecer un nombre diferente a su registrador de clases, puede usar esto:

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

Y, como dijo @JeremyWiebe, no tiene que usar trucos para obtener el nombre de la clase que está tratando de registrar un mensaje: El nombre del registrador (que generalmente es el nombre de la clase) se puede registrar fácilmente en el archivo (u otro destino) utilizando ${logger} en layout.

Puedo ver algunas razones para esta elección.

• Siempre sabrá de dónde proviene una instrucción de registro en particular, si incluye el nombre del registrador en su formato de salida de registro.
• Puede controlar qué instrucciones de registro ve en un nivel de grano fino activando o desactivando ciertos registradores, o configurando su nivel.

En la mayoría de los casos, el nombre de la clase proporciona un buen nombre para el registrador. Al escanear los archivos de registro, puede ver el mensaje de registro y asociarlo directamente con una línea de código.

Un buen ejemplo donde este no es el mejor enfoque, son los logs SQL de Hibernate. Hay un registrador compartido llamado " Hibernate.SQL " o algo así, donde un número de clases diferentes escriben SQL sin procesar en una sola categoría de registrador.

También hay un beneficio de rendimiento en el caso de NLog. La mayoría de los usuarios usarán

Logger logger = LogManager.GetCurrentClassLogger()

Buscar la clase actual de stack trace requiere algo de rendimiento (pero no mucho).

Desde el punto de vista del desarrollo, es más fácil si no tiene que crear un objeto logger cada vez. Por otro lado, si no lo haces, sino que lo creas dinámicamente usando reflexión, ralentizará el rendimiento. Para resolver esto, puede usar el siguiente código que crea el registrador de forma dinámica y asíncrona:

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);

        }
    }
}

Dos razones vienen inmediatamente a la mente:

1. Tener un registro separado para cada clase hace que sea fácil agrupar todos los mensajes/errores de registro pertenecientes a una clase dada.
2. Tener un registro dentro de una clase le permite registrar detalles internos que pueden no ser accesibles fuera de la clase (por ejemplo, estado privado, información relacionada con la implementación de una clase, etc.).).

Probablemente porque desea poder registrar métodos que solo son visibles para la clase sin romper la encapsulación, esto también hace que sea fácil usar la clase en otra aplicación sin romper la funcionalidad de registro.

Facilita la configuración de los appenders por espacio de nombres o clase.

Si está utilizando NLOG, puede especificar el callsite en la configuración, esto registrará el nombre de la clase y el método donde se encuentra la instrucción logging.

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

Entonces podría usar una constante para el nombre de su registrador o el nombre del ensamblado.

Descargo de responsabilidad: No se cómo NLOG recopila esta información, mi conjetura sería reflexión por lo que puede que tenga que considerar el rendimiento. Hay algunos problemas con los métodos asincrónicos si no está utilizando NLOG v4.4 o posterior.