Архитектура делегатов и событий с помощью Logger

Question

Вопрос: Существует ли более простой способ создания этого кода регистрации с использованием событий?

Код, вдохновленный великолепной речью @JonSkeets на www.tekpub.com. Все ошибки в понимании мои.

internal class Program
{
    private static void Main(string[] args)
    {
        Person p = new Person();
        p.GetDefaultName();
    }
}

public delegate void LogHandler(string message);

public class Person
{
    public void GetDefaultName()
    {
        LogEventRaiser raiser = SetupLogEventRaiser();
        raiser.OnLog("getting default name");
    }

    private static LogEventRaiser SetupLogEventRaiser()
    {
        ConsoleLogger cl = new ConsoleLogger();
        ConsoleLogger2 cl2 = new ConsoleLogger2();

        //when delegate LogHander is called, run fileLogger.Logger method
        LogHandler handler = cl.Logger;
        LogHandler handler2 = cl2.Logger;

        var raiser = new LogEventRaiser();
        //wire up event called Log which is of type delegate LogHandler
        raiser.Log += handler;
        raiser.Log += handler2;
        return raiser;
    }
}

public class LogEventRaiser
{
    public event LogHandler Log;

    public void OnLog(string text)
    {
        LogHandler tmp = Log;
        if (tmp != null)
            tmp.Invoke(text);
    }
}

public class ConsoleLogger
{
    public void Logger(string s)
    {
        Console.WriteLine("ConsoleLogger: " + s);
    }

}

public class ConsoleLogger2
{
    public void Logger(string s)
    {
        Console.WriteLine("ConsoleLogger2: " + s);
    }
}

Answer 1

Рассматривали ли вы структуру ведения журналов, например, NLog (http://nlog -project.org /)?

Это позволит вам разделить ведение журнала и цели.Не нужно жестко кодировать цели.Он также имеет преимущество уровней ведения журнала и низкой загрузки ЦП, если уровень ведения журнала отключен.

Answer 2

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

Если вам нужна высокая производительность / пропускная способность, вам понадобятся очереди сообщений журнала, чтобы вызываемый код не блокировал действие журнала.Если вам нужна высокая уверенность в том, что сообщение журнала действительно отправлено, вам понадобится механизм обратной связи и «много» кода обработки ошибок.Если вы будете использовать это для регистрации производительности, вам может быть даже лучше с профилировщиком производительности.

Я бы сказал, Keep It Simple и перейти оттуда.