Flex Logging Framework 的最佳实践

原文见于： http://blogs.adobe.com/tomsugden/2009/08/best_practices_for_the_flex_lo.html

导读

　　Flex Logging Framework 易学好用的技术。在帮助开发者调试代码以及在应用程序发生错误时将错误信息反馈回远程服务器等一些情况下非常有用。欲了解 Flex Logging Framework 的基本用法可参考 Flex Developer Guide 的相关章节。该文档提供了若干在开发企业应用时使用 Flex Logging Framework 的最佳实践。

  Flex Logging Framework 提供的 API 相当简单，但只有掌握了它们的正确使用方法才能使效能最大化。如不遵循它们的用法，就难以得到那些在调试和监测应用程序错误时本应获得便利性。甚至会产生性能问题。本文提供了一些让团队开发人员在如何正确使用 Flex Logging Framework 上的一些最佳实践。

最佳实践

本文的最佳实践函盖了以下方面：

• 通过 Class 获得日志记录器 ；
• 将 Loggers 声明为静态实例 ；
• 总是使日志表达式格式化输出 ；
• 将日志表达式用 Token 参数化 ；
• 通过日志级别来表示重要度 ；
• 通过日志过滤器来聚焦重点 ；
• 显示类名时要包含目录 ；
• 适时使用输出等级判定 ；
• 在运行时配置日志环境 ；

通过 Class 获得日志记录器

  比通过一个类的全限定性名来获得日志记录器的一个更好的方法是， 将某特定类本身传递给一个简单的实用函数来得对应该类的日志记录器。

优：

private static const LOG:ILogger = LogUtil.getLogger(MyClass);

劣：

private static const LOG:ILogger = Log.getLogger(“my.package.MyClass”);

　　以上实用函数会自动返回类名称而无需改动字符串。以下是 LogUtil.getLogger() 的具体实现：

public static function getLogger(c:Class):ILogger 
{
    var className:String =  
        getQualifiedClassName(c).replace("::", ".")
    return Log.getLogger(className);
}

　　或许在执行概要分析时会显示该实用方法的调用是一个性能瓶颈，而你会通过将传递的内容改回字符串而获得少许运行速度。但在大多数情况下用上面的方法获得的便利性和可重构性才是最佳实践。



将日志记录器声明为静态实例

　　通常情况下，日志表达式是对应到特定类，所以一个日志记录器应该被声明为静态实例而不是一个实例变量。

优：

private static const LOG:ILogger = LogUtil.getLogger(MyClass);

劣：

private var log:ILogger = LogUtil.getLogger(MyClass);

总是使日志表达式格式化输出

　　应坚持对日志表达式进行格式化而非随心所欲。这会使你的日志代码看起来具有专业水准并且可以提高日志文件的可读性（无论人读或机读）。

优：

LOG.error(
    "Something bad has happened: event={0}, message={1}", 
    event.type, 
    message);

劣：

LOG.error("-----------  SOMETHING BAD HAS HAPPENED!  -----------------");

参数化日志表达式

　　应该使用rest参数和 tokens 来参数化日志表达式，而不是手动拼接字符串。这种方式能生成整洁的代码并避免在未注册日志目标的事件中拼装复合字符串（This produces cleaner code and prevents the composite string from being assembled in the event that no log target is registered）。

优：

LOG.debug(
    "Something interesting is happening: event={0}, message={1}", 
    event.type, 
    message);

劣：

LOG.debug(
    "Something interesting is happening: event=" + 
    event.type + 
    ", message=" + 
    message);

通过日志记录级别来表示重要度

　　应该利用 debug/info/warn/error 日志记录级别来表达信息的重要程度。而不是使用语气化的特殊字符来表示重要的信息。

优：

LOG.error("The service has failed and no data is available.");

劣：

LOG.debug("!!! ERROR !!! The service has failed !!! ERROR !!!");

通过日志过滤器来聚焦重点

　　可以通过在日志目标上设置日志过滤器使之仅聚焦到系统特定部分的日志输出。不要想当然的使用一些吸引眼球的怪字符来作为日志表达式。牢记始终格式化日志消息的输出。

优：

target.filters = [ "my.important.package.MyClass" ];
target.level = LogEventLevel.INFO;
...
LOG.info("My important message");

劣：

LOG.debug("----------- My really important message! -----------");
LOG.debug("<<<<<<<    another super important log!    >>>>>>>>");
LOG.debug("************* CAN YOU SEE ME????? ***************");

　　用“怪字符”的麻烦在于此时此刻的你所谓的重点和他日其他开发人员所认为的重点会不一样，难以做到心有灵犀。假如每个人都用自己的一套日志表达风格，那么将导致最终的日志难以阅读。日志记录级别和过滤器为开发过程中的信息记录提供了一种更为可控和一致的表达机制。



显示类名时要包含目录

　　假如你想知道某日志记录的对应类名，那么请在日志对象中包含目录。不要在日志记录中硬编码类名。

优：

target.includeCategory = true;
...
LOG.debug("Executing command");

劣：

LOG.debug("<<<   Executing SynchronizationCommand   >>>");

　　上述的劣等实践不是“重构安全”的。一旦类名被重设，日志信息会变得错乱，另外将目录名包含到输出内容中时，整个信息将会变得十分冗长。



适时使用输出等级判定

　　利用输出等级判定来避免不必要的运算过程，特别是在循环和迭代代码中不加甄别的记录日志其代价高昂。然而也不必在每个单条日志记录语句上都附加条件判断以至于使代码变得脏乱。可以通过概要分析来查看日志记录是否是代价高昂的。

优：

if (Log.isDebug())
{
    LOG.debug("Result received: {0}", ObjectUtil.toString(model));
}

for (var i:int = 0; i<10000; i++)
{
    if (Log.isDebug())
    {
        LOG.debug("Blah blah blah: i={0}", i);
    }
}

劣：

LOG.debug("Result received: {0}", ObjectUtil.toString(model));

for (var i:int = 0; i<10000; i++)
{
   LOG.debug("Blah blah blah: i={0}", i);
   ...
}

　　上述劣等实践中，model 即使在 debug 等级上没有日志对象被注册的情况下仍旧会被转换成字符串。类似的，一万条日志记录会被不分青红皂白的输出来。



在运行时配置日志

　　在运行时配置日志作为一个最佳实践的原因在于它允许开发者变更他们的日志过滤器而无需重新编译整个项目，同时也允许日志在生产阶段重新配置而无需再次部署。甚至可以做到不同的用户对应到不同的日志设定。

　　日志的运行时配置流程不在本文的叙述范围内。有需要的同学可以参考 Parsley 2 Application Framework 。该框架提供了读取额外 xml 文件中指定的 targets, levels 以及 filters 设置并在运行时对日志准确配置的特性。关于如何使用 Prana/Spring ActionScript 达到同样目的，上述框架所在地有也有举例。


tsugden 发表于 2009-08-11 早 9:15
bigt 翻译于 2011-02-21 晚 23:30

相关链接：
A Declarative Approach to Flex Popups
The Trend Towards Inversion-of-Control Frameworks in Flex