На что был бы похож класс Обертки Log4Net?

По существу Вы создаете интерфейс и затем конкретную реализацию того интерфейса, который обертывает классы и методы Log4net непосредственно. Дополнительные системы регистрации могут быть обернуты путем создания более реальных классов, которые обертывают другие классы и методы тех систем. Наконец используйте фабрику для создания экземпляров оберток на основе параметра конфигурации или строки изменения кода. (Отметьте: можно стать более гибкими - и комплекс - использование Инверсия Управления контейнер такой как StructureMap.)

public interface ILogger
{
    void Debug(object message);
    bool IsDebugEnabled { get; }

    // continue for all methods like Error, Fatal ...
}

public class Log4NetWrapper : ILogger
{
    private readonly log4net.ILog _logger;

    public Log4NetWrapper(Type type)
    {
        _logger = log4net.LogManager.GetLogger(type);
    }

    public void Debug(object message)
    {
        _logger.Debug(message);
    }

    public bool IsDebugEnabled
    {
        get { return _logger.IsDebugEnabled; }
    }

    // complete ILogger interface implementation
}

public static class LogManager
{
    public static ILogger GetLogger(Type type)
    {
        // if configuration file says log4net...
        return new Log4NetWrapper(type);
        // if it says Joe's Logger...
        // return new JoesLoggerWrapper(type);
    }
}

И пример использования этого кода в Ваших классах (объявленный как статическое поле только для чтения):

private static readonly ILogger _logger =
    LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);

можно получить то же немного больше производительности дружественное использование эффекта:

private static readonly ILogger _logger = 
    LogManager.GetLogger(typeof(YourTypeName));

Бывший пример считают более удобным в сопровождении.

Вы не хотели бы создавать Singleton для обработки всего входа, потому что Log4Net регистрируется для типа вызова; его намного более чистый и полезный для имения каждого типа используют его собственный регистратор вместо того, чтобы просто видеть единственный тип в файле журнала, сообщая обо всех сообщениях.

, поскольку Ваша реализация должна быть довольно допускающей повторное использование (другие проекты в Вашей организации) Вы могли сделать ее ее собственным блоком или идеально включать ее с Вашим собственным персональным блоком платформы/утилиты / блоком платформы/утилиты организации. Не повторно объявляйте классы отдельно в каждом из Ваших блоков бизнеса/данных/UI, это не удобно в сопровождении.

Принятие Вас шло с чем-то как ответ cfeduke выше , Вы могли также добавить перегрузку к Вашему LogManager как это:

public static ILogger GetLogger()
{
    var stack = new StackTrace();
    var frame = stack.GetFrame(1);
    return new Log4NetWrapper(frame.GetMethod().DeclaringType);
}

Тот путь в Вашем коде можно теперь просто использовать:

private static readonly ILogger _logger = LogManager.GetLogger();

вместо любого из них:

private static readonly ILogger _logger =
    LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);
private static readonly ILogger _logger = 
    LogManager.GetLogger(typeof(YourTypeName));

, Который эффективно эквивалентен из первой альтернативы (т.е. тот, который использует MethodBase.GetCurrentMethod().DeclaringType), только немного более простой.

Какие преимущества - Вы планирование выхода из записи обертки для log4net. Я рекомендовал бы стать довольным log4net классами сначала прежде, чем записать обертку вокруг них. cfeduke является правильным в его ответе о том, как записать, сказала обертка, но если Вы не должны добавлять фактическую функциональность к его примеру, обертка только преуспела бы в том, чтобы замедлить процесс входа и добавление сложности для будущих специалистов по обслуживанию. Это особенно верное при рефакторинге инструментов, доступных в.Net, делает такие изменения супер легкими.

Мое понимание - то, что класс обертки для log4net был бы статическим классом, который заботится об инициализации регистрирующегося объекта от app.config/web.config или кодом (например, интеграция с NUnit).

возможное применение для log4net обертки могло быть классом, который заставляет класс вызова и метод через отражение понимать то, где Ваша запись входа произошла. по крайней мере, я часто использую это.

Альконья, мне нравится твоя идея использовать трассировку стека для возврата к вызывающему методу. Я думал о дальнейшей инкапсуляции вызовов, чтобы не просто получить объект регистратора, но и выполнить собственно регистрацию. Мне нужен статический класс, который обрабатывает ведение журнала, абстрагируясь от конкретной используемой реализации. Т.е.

LoggingService.LogError("my error message");

Таким образом мне нужно будет изменить только внутреннее устройство статического класса, если я позже решу использовать другую систему журналирования.

Итак, я использовал вашу идею, чтобы получить вызывающий объект с помощью трассировки стека:

public static class LoggingService
{
    private static ILog GetLogger()
    {    
        var stack = new StackTrace();    
        var frame = stack.GetFrame(2);    
        return log4net.LogManager.GetLogger(frame.GetMethod().DeclaringType);
    }

    public static void LogError(string message)
    {
        ILog logger = GetLogger();
        if (logger.IsErrorEnabled)
            logger.Error(message);
    }
    ...
}

Кто-нибудь видит проблему с этим подходом?