Найкраща практика обгортки журналу

Я хочу використовувати nlogger у своїй програмі, можливо, у майбутньому мені доведеться змінити систему реєстрації. Тому я хочу використовувати фасад лісозаготівлі.

Чи знаєте ви якісь рекомендації щодо існуючих прикладів, як їх писати? Або просто дайте мені посилання на найкращі практики в цій галузі.

Раніше я використовував фасади реєстрації, такі як Common.Logging (навіть для того, щоб приховати власну бібліотеку CuttingEdge.Logging ), але сьогодні я використовую шаблон введення залежності, і це дозволяє мені приховувати реєстратори за власною (простою) абстракцією, яка дотримується обох залежностей Принцип інверсії та Принцип сегрегації інтерфейсу(ISP), оскільки він має одного члена і тому, що інтерфейс визначається моєю програмою; не зовнішня бібліотека. Тим менше, мінімізуючи знання основних частин вашої програми про існування зовнішніх бібліотек; навіть якщо ви не маєте наміру ніколи замінювати свою бібліотеку реєстрації. Важка залежність від зовнішньої бібліотеки ускладнює тестування коду та ускладнює програму за допомогою API, який ніколи не був розроблений спеціально для вашої програми.

Ось так часто виглядає абстракція в моїх додатках:

public interface ILogger
{
    void Log(LogEntry entry);
}

public enum LoggingEventType { Debug, Information, Warning, Error, Fatal };

// Immutable DTO that contains the log information.
public class LogEntry 
{
    public readonly LoggingEventType Severity;
    public readonly string Message;
    public readonly Exception Exception;

    public LogEntry(LoggingEventType severity, string message, Exception exception = null)
    {
        if (message == null) throw new ArgumentNullException("message");
        if (message == string.Empty) throw new ArgumentException("empty", "message");

        this.Severity = severity;
        this.Message = message;
        this.Exception = exception;
    }
}

За бажанням, цю абстракцію можна розширити за допомогою деяких простих методів розширення (що дозволяє інтерфейсу залишатися вузьким і дотримуватися Інтернету). Це робить код для споживачів цього інтерфейсу набагато простішим:

public static class LoggerExtensions
{
    public static void Log(this ILogger logger, string message) {
        logger.Log(new LogEntry(LoggingEventType.Information, message));
    }

    public static void Log(this ILogger logger, Exception exception) {
        logger.Log(new LogEntry(LoggingEventType.Error, exception.Message, exception));
    }

    // More methods here.
}

Оскільки інтерфейс містить лише один метод, ви можете легко створити ILoggerреалізацію, яка проксі-сервери log4net , Serilog , Microsoft.Extensions.Logging , NLog або будь-яку іншу бібліотеку ведення журналів та налаштувати свій контейнер DI, щоб вводити його в класи, які мають ILoggerу своєму конструктор.

Зверніть увагу, що наявність методів статичного розширення поверх інтерфейсу з одним методом цілком відрізняється від інтерфейсу з багатьма членами. Методи розширення - це лише допоміжні методи, які створюють LogEntryповідомлення та передають його через єдиний метод на ILoggerінтерфейсі. Методи розширення стають частиною коду споживача; не є частиною абстракції. Це не тільки дозволяє методам розширення еволюціонувати без необхідності змінювати абстракцію, методи розширення таLogEntryконструктор завжди виконується, коли використовується абстракція реєстратора, навіть коли цей реєстратор заглушений / знущається. Це дає більшу впевненість у правильності викликів реєстратора під час запуску в наборі тестів. Одночленний інтерфейс також значно полегшує тестування; Наявність абстракції з багатьма членами ускладнює створення реалізацій (таких як макети, адаптери та декоратори).

Коли ви робите це, навряд чи колись виникає потреба в якійсь статичній абстракції, яку можуть запропонувати фасади реєстрації (або будь-яка інша бібліотека).

Я використовував невелику обгортку інтерфейсу + адаптер з https://github.com/uhaciogullari/NLog.Interface, який також доступний через NuGet :

PM> Install-Package NLog.Interface 

На сьогоднішній день найкращим варіантом є використання пакета Microsoft.Extensions.Logging ( як зазначив Джуліан ). З цим можна використовувати більшість фреймворків журналювання.

Визначення власного інтерфейсу, як пояснюється у відповіді Стівена, є нормальним для простих випадків, але воно пропускає кілька речей, які я вважаю важливими:

• Структуровані об'єкти ведення журналу та деструктуризації (позначення @ у Serilog та NLog)
• Затримка побудови / форматування рядків: оскільки вона приймає рядок, вона повинна оцінити / відформатувати все при виклику, навіть якщо врешті-решт подія не буде зареєстрована, оскільки вона нижче порогової (вартість продуктивності, див. Попередній пункт)
• Умовні перевірки, подібні до того, IsEnabled(LogLevel)які вам можуть знадобитися, ще раз з міркувань ефективності

Можливо, ви можете реалізувати все це у своїй власній абстракції, але в цей момент ви будете винаходити колесо.

Як правило, я вважаю за краще створювати такий інтерфейс, як

public interface ILogger
{
 void LogInformation(string msg);
 void LogError(string error);
}

а під час виконання я ввожу конкретний клас, який реалізований з цього інтерфейсу.

Чудове рішення цієї проблеми з’явилося у вигляді проекту LibLog .

LibLog - це абстракція журналів із вбудованою підтримкою основних реєстраторів, включаючи Serilog, NLog, Log4net та Enterprise logger. Він встановлюється через менеджер пакунків NuGet у цільову бібліотеку як вихідний (.cs) файл замість посилання .dll. Цей підхід дозволяє включити абстракцію журналу, не змушуючи бібліотеку приймати зовнішню залежність. Це також дозволяє автору бібліотеки включати ведення журналу, не змушуючи програму-споживача явно надавати реєстратор бібліотеці. LibLog використовує рефлексію, щоб зрозуміти, який конкретний реєстратор використовується, і підключити до нього без явного коду підключення в проекті бібліотеки.

Отже, LibLog - чудове рішення для ведення журналу в бібліотечних проектах. Просто наведіть посилання та налаштуйте конкретний реєстратор (Serilog для перемоги) у вашому основному додатку чи службі та додайте LibLog до своїх бібліотек!

Замість того, щоб писати власний фасад, ви можете скористатися послугами Castle Logging Services або Simple Logging Façade .

Обидва вони включають адаптери для NLog та Log4net.

З 2015 року ви також можете використовувати .NET Core Logging, якщо створюєте основні програми .NET.

Пакет для NLog:

• NLog.Web.AspNetCore для користувачів ASP.NET Core
• NLog.Extensions. Ведення журналу для користувачів .NET Core, наприклад консольних проектів