Отделение кода ведения журнала от объектов 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://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. Это реализуется с помощью атрибутов и отражения. Вы отмечаете каждый метод, который хотите войти определенным образом и наслаждаться. Я полагаю, что может быть лучший способ сделать это, может быть, с помощью шаблона наблюдателя или чего-то еще, но пока я думал об этом, я не мог придумать ничего лучшего.
в основном, такие проблемы называются сквозные проблемы и могут быть решены с помощь АОП.
Я также думаю, что некоторая интересная схема наследования может быть применена с сущностями журнала в базе, но я бы пошел на фильтры