Отделение кода ведения журнала от объектов C#

В настоящее время у меня есть пользовательский класс статического ведения журнала в C#, который можно вызвать со следующим кодом:

EventLogger.Log(EventLogger.EventType.Application, string.Format("AddData request from {0}", ipAddress));

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

однако, в том, что я должен войти много-много событий, мой код становится трудно читать, потому что все сообщения.

есть ли установленный способ более или менее отделить код ведения журнала от объектов и методов в класс C#, чтобы код не стал непослушным?

спасибо всем заранее за вашу помощь, так как это то, что я боролся в последнее время.

7 ответов


Мне нравятся функции AOP, которые предлагает PostSharp. На мой взгляд, Loggin-это аспект любого программного обеспечения. Ведение журнала не является основным значением, которое должно предоставлять приложение.

Так что в моем случае PostSharp всегда был в порядке. Spring.NET имеет также модуль AOP, который может быть использован для достижения этой цели.


наиболее часто используемая техника, которую я видел, использует AOP в той или иной форме.

PostSharp один продукт который делает Ил соткать как форма АОП, хотя не единственный способ сделать AOP в .NET.


решением этого является использование аспектно-ориентированное программирование в котором вы можете разделить эти опасения. Это довольно сложное/инвазивное изменение, поэтому я не уверен, что это возможно в вашей ситуации.


У меня был пользовательский встроенный регистратор, но недавно он был изменен на TracerX. Это обеспечивает простой способ инструментирования кода с различными уровнями серьезности. Регистраторы могут быть созданы с именами, тесно связанными с классом и т. д., с которым вы работаете

Он имеет отдельный просмотрщик с большим количеством возможностей фильтрации, включая регистратор, серьезность и так далее.

http://tracerx.codeplex.com/

здесь есть статья об этом: http://www.codeproject.com/KB/dotnet/TracerX.aspx


Если ваша основная цель-регистрировать точки входа/выхода функции и случайную информацию между ними, у меня были хорошие результаты с одноразовая объект регистрации, где конструктор отслеживает запись функции и Dispose () трассирует выход. Это позволяет вызывающему коду просто обернуть код каждого метода внутри одного используя заявление. Методы также предусмотрены для произвольных журналов между ними. Вот полный класс трассировки событий c# ETW вместе с оболочкой входа/выхода функции:

using System;
using System.Diagnostics;
using System.Diagnostics.Tracing;
using System.Reflection;
using System.Runtime.CompilerServices;

namespace MyExample
{
    // This class traces function entry/exit
    // Constructor is used to automatically log function entry.
    // Dispose is used to automatically log function exit.
    // use "using(FnTraceWrap x = new FnTraceWrap()){ function code }" pattern for function entry/exit tracing
    public class FnTraceWrap : IDisposable
    {
        string methodName;
        string className;

        private bool _disposed = false;

        public FnTraceWrap()
        {
            StackFrame frame;
            MethodBase method;

            frame = new StackFrame(1);
            method = frame.GetMethod();
            this.methodName = method.Name;
            this.className = method.DeclaringType.Name;

            MyEventSourceClass.Log.TraceEnter(this.className, this.methodName);
        }

        public void TraceMessage(string format, params object[] args)
        {
            string message = String.Format(format, args);
            MyEventSourceClass.Log.TraceMessage(message);
        }

        public void Dispose()
        {
            if (!this._disposed)
            {
                this._disposed = true;
                MyEventSourceClass.Log.TraceExit(this.className, this.methodName);
            }
        }
    }

    [EventSource(Name = "MyEventSource")]
    sealed class MyEventSourceClass : EventSource
    {
        // Global singleton instance
        public static MyEventSourceClass Log = new MyEventSourceClass();

        private MyEventSourceClass()
        {
        }

        [Event(1, Opcode = EventOpcode.Info, Level = EventLevel.Informational)]
        public void TraceMessage(string message)
        {
            WriteEvent(1, message);
        }

        [Event(2, Message = "{0}({1}) - {2}: {3}", Opcode = EventOpcode.Info, Level = EventLevel.Informational)]
        public void TraceCodeLine([CallerFilePath] string filePath = "",
                                  [CallerLineNumber] int line = 0,
                                  [CallerMemberName] string memberName = "", string message = "")
        {
            WriteEvent(2, filePath, line, memberName, message);
        }

        // Function-level entry and exit tracing
        [Event(3, Message = "Entering {0}.{1}", Opcode = EventOpcode.Start, Level = EventLevel.Informational)]
        public void TraceEnter(string className, string methodName)
        {
            WriteEvent(3, className, methodName);
        }

        [Event(4, Message = "Exiting {0}.{1}", Opcode = EventOpcode.Stop, Level = EventLevel.Informational)]
        public void TraceExit(string className, string methodName)
        {
            WriteEvent(4, className, methodName);
        }
    }
}

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

public void DoWork(string foo)
{
    using (FnTraceWrap fnTrace = new FnTraceWrap())
    {
        fnTrace.TraceMessage("Doing work on {0}.", foo);
        /*
        code ...
        */
    }
}

для повышения читаемости кода, только то, что вам действительно нужно (информация/предупреждение/ошибка). Регистрируйте сообщения отладки во время разработки, но удаляйте большинство, когда закончите. Для трассировки, используйте AOP для регистрации простых вещей, таких как метод входа/выхода (если вы чувствуете, что вам нужна такая гранулярность).

пример:

public int SomeMethod(int arg)
{
   Log.Trace("SomeClass.SomeMethod({0}), entering",arg);  // A
   if (arg < 0)
   {
      arg = -arg;
      Log.Warn("Negative arg {0} was corrected", arg);    // B
   }
   Log.Trace("SomeClass.SomeMethod({0}), returning.",arg);  // C
   return 2*arg;
}

в этом примере единственным необходимым оператором журнала является B. операторы журнала A и C являются шаблоном, ведение журнала, которое вы можете оставить PostSharp для вставки вместо этого ты.

также: в вашем примере вы можете видеть, что существует некоторая форма "действия X, вызываемого Y", которая предполагает, что большая часть вашего кода может быть перемещена на более высокий уровень (например, команда/фильтр).

ваше распространение операторов ведения журнала может сказать вам что-то: что может быть использована какая-то форма шаблона проектирования, которая также может централизовать большую часть ведения журнала.

void DoSomething(Command command, User user)
{
   Log.Info("Command {0} invoked by {1}", command, user);
   command.Process(user);
}

Я думаю, что это хороший вариант для реализации чего-то похожего на фильтры в ASP.NET MVC. Это реализуется с помощью атрибутов и отражения. Вы отмечаете каждый метод, который хотите войти определенным образом и наслаждаться. Я полагаю, что может быть лучший способ сделать это, может быть, с помощью шаблона наблюдателя или чего-то еще, но пока я думал об этом, я не мог придумать ничего лучшего.

в основном, такие проблемы называются сквозные проблемы и могут быть решены с помощь АОП.

Я также думаю, что некоторая интересная схема наследования может быть применена с сущностями журнала в базе, но я бы пошел на фильтры