Вопрос

Я рассматриваю возможность использования фреймворка Postsharp, чтобы облегчить ведение журнала прикладных методов.По сути, это позволяет мне украшать методы атрибутом logging и во время компиляции вставлять необходимый код протоколирования в il.Мне нравится это решение, поскольку оно убирает шум из среды соизволения использовать тайм-код.Есть какие-нибудь мысли, опыт или лучшие альтернативы?

Это было полезно?

Решение

Я применяю ведение журнала с помощью AOP, используя Castle Windsor DynamicProxies.Я уже использовал Castle для своего контейнера IoC, поэтому использование его для AOP было для меня путем наименьшего сопротивления.Если вам нужна дополнительная информация, дайте мне знать, я нахожусь в процессе приведения в порядок кода для публикации его в виде поста в блоге

Редактировать

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

Абстрактный базовый класс

namespace Tools.CastleWindsor.Interceptors
{
using System;
using System.Text;
using Castle.Core.Interceptor;
using Castle.Core.Logging;

public abstract class AbstractLoggingInterceptor : IInterceptor
{
    protected readonly ILoggerFactory logFactory;

    protected AbstractLoggingInterceptor(ILoggerFactory logFactory)
    {
        this.logFactory = logFactory;
    }

    public virtual void Intercept(IInvocation invocation)
    {
        ILogger logger = logFactory.Create(invocation.TargetType);

        try
        {
            StringBuilder sb = null;

            if (logger.IsDebugEnabled)
            {
                sb = new StringBuilder(invocation.TargetType.FullName).AppendFormat(".{0}(", invocation.Method);

                for (int i = 0; i < invocation.Arguments.Length; i++)
                {
                    if (i > 0)
                        sb.Append(", ");

                    sb.Append(invocation.Arguments[i]);
                }

                sb.Append(")");

                logger.Debug(sb.ToString());
            }

            invocation.Proceed();

            if (logger.IsDebugEnabled && invocation.ReturnValue != null)
            {
                logger.Debug("Result of " + sb + " is: " + invocation.ReturnValue);
            }
        }
        catch (Exception e)
        {
            logger.Error(string.Empty, e);
            throw;
        }
    }
}
}

Полная реализация протоколирования

namespace Tools.CastleWindsor.Interceptors
{
using Castle.Core.Logging;

public class LoggingInterceptor : AbstractLoggingInterceptor
{
    public LoggingInterceptor(ILoggerFactory logFactory) : base(logFactory)
    {
    }
}
}

Протоколирование метода

namespace Tools.CastleWindsor.Interceptors
{
using Castle.Core.Interceptor;
using Castle.Core.Logging;
using System.Linq;

public class MethodLoggingInterceptor : AbstractLoggingInterceptor
{
    private readonly string[] methodNames;

    public MethodLoggingInterceptor(string[] methodNames, ILoggerFactory logFactory) : base(logFactory)
    {
        this.methodNames = methodNames;
    }

    public override void Intercept(IInvocation invocation)
    {
        if ( methodNames.Contains(invocation.Method.Name) )
            base.Intercept(invocation);
    }
}
}

Другие советы

+1 к пострезкости.Использую для нескольких целей (включая некоторые попытки добавления предварительных условий и постусловий в код C #) и не знаю, как бы я справился без этого...

В какой-то степени это зависит от того, как долго вы будете разрабатывать и поддерживать проект.Конечно, IL-ткачество - хорошая технология, но что произойдет, если формат метаданных IL и / или сборки снова изменится (как это было между 1.1 и 2.0), и эти изменения сделают инструмент несовместимым с новым форматом?

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

Хотя в краткосрочной перспективе никаких проблем.

Использовали его именно для этого.Отлично работает!Я бы очень рекомендовал это!

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top