2011-03-24 100 views
11

这个问题在我的脑海中唠叨了一段时间...对于日志记录是有用的,它应该是代码中的每一处,但是这会使代码难以阅读。像下面的代码:介绍没有源代码污染的日志记录

public IDictionary<decimal, Status> GetStatus(decimal[] keys) 
{ 
    _logger.Debug("ENTERED GetStatus"); 

    IDictionary<decimal, Status> statuses = new Dictionary<decimal, Status>(); 
    string inClause = null; 

    inClause = FormatInClause(keys, inClause); 
    _logger.DebugFormat(" inClause: '{0}' ", inClause); 
    if (string.IsNullOrEmpty(inClause)) 
    { 
     _logger.Error("Key collection is null or empty."); 
     throw new Exception("Key collection is null or empty."); 
    } 

    if (!IsOpen) 
     Connection.Open(); 

    using (IDbCommand cmd = Connection.CreateCommand()) 
    { 
     cmd.CommandText = " select id, date, status " + 
      " from ORDERS where id in (" + inClause + ") "; 

     inClause = null; 

     using (IDataReader reader = cmd.ExecuteReader()) 
     { 
      int i = 0; 
      while (reader.Read()) 
      { 
       object[] values = new object[reader.FieldCount]; 

       reader.GetValues(values); 
       DebugHelper.LogValues(_logger, " reader.Read() #" + i + " reader.GetValues(values): ", values); 

       statuses[(decimal)values[0]] = new Status(
        (decimal)values[0], 
        ValueOrDefult<string>(values[1]), 
        ValueOrDefult<string>(values[2]), 
        (decimal)values[3], 
        ValueOrDefult<DateTime>(values[4])); 
       _logger.DebugFormat(" reader.Read() #{0} created new Status() ", i); 

       values = null; 
       i++; 
      } 
     } 
    } 

    _logger.Debug("EXITED GetStatus"); 
    return statuses; 
} 

是否有一些记录策略不降低源代码的可读性?

回答

7

Aspect oriented programming应该帮助像cross-cutting concerns记录,例如。 postsharp但是你不能真正对记录内容有非常细致的控制,除非你诉诸更传统的方法

+0

打我吧:) – Pondidum 2011-03-24 14:39:36

+0

同意。 PostSharp将处理输入/退出类型记录。我已经用它来做这件事。很酷的是PostSharp实际上可以写出参数的值。 – RQDQ 2011-03-24 14:40:10

+1

Unity Framework也提供了AOP,就像Spring.NET – DaveRead 2011-03-24 14:41:58

-2

你的源代码对我来说看起来很好...实际上它看起来最好,因为我可以看到日志消息并确定每条消息之间的内容。

即使有一件事情让我困扰,它确实是__logger

一些日志记录API往往提出缩短的API,如:

l.d("debug") 
l.c("critical") 
...etc 

的方式上面或用自己的方式都是不错恕我直言。

编辑

如果你还是想做点什么,只是包装你的日志行到#regions和折叠他们。

+6

我不同意命名标准。所有变量和方法名称应该是描述性的,包括用于记录的变量和方法名称。在代码中混用标准会让阅读变得更加困难。 – jgauffin 2011-03-24 14:39:54

+0

Imho这是一个味道的问题。如果你做的是l.c(“”)的东西,但只有**你的调试,我不认为这会伤害源码的可读性。实际上它会突出显示消息本身,而不是记录函数的调用。直到今天,我都使用过,而且我根本没有可读性问题。 – CoolStraw 2011-03-24 14:43:03

1

你可以遵循一些规则。

1)只记录你实际上与他们“交易”的错误。

2)使用AOP来包装你的方法,所以你不必在进入和退出所有方法时都有调试语句。您也可以让AOP调用记录方法的输入和输出参数/响应。

3

恕我直言,你的日志是凌乱的,因为你的代码是这么觉得。您应该阅读SOLID原则。

例如,将阅读器代码移至单独的方法。

+0

谢谢我将研究您在我的示例中指出的问题 – 2011-03-24 17:47:31