依赖注入和日志接口

我想知道一些最佳实践是围绕日志和日志框架和依赖注入。具体来说,如果我设计一个需要日志记录的类,我应该如何获得一个接口来记录依赖注入?

依赖注入似乎声明外部依赖应该从外部注入(构造函数或属性setters),所以我应该在构造函数中使用ILog实例并在类中使用?我应该考虑记录一个可选的依赖项并在setter中获取它吗?我通过允许日志接口改变,我只是对一个特定的日志接口(通过例如通过调用工厂方法创建一个静态ILog变量)硬依赖推动太多的灵活性?可能这个工厂方法调用到容器中以获得ILog实现,或者这将创建初始化的静态变量和初始化IoC容器之间的初始化冲突?

我应该这样做:

public class MyService : ISomeService
{
  private static readonly ILogger s_log = 
            LoggingFactory.GetLogger(typeof(MyService))
  ...
}

或者也许这:

public class MyService : ISomeService
{
  protected virtual ILogger Logger {get; private set;}
  public MyService(ILogger logger,[other dependencies])
  {
    Logger = logger;
  }
}

或甚至这:

public class MyService : ISomeService
{
  public virtual ILogger Logger {get; set;}
  public MyService()
  {
  }
}

其他模式或方法来做到这一点?什么人在那里做?什么是工作和什么时候?

这是伟大的,你正在寻找反转控制和依赖注入。

但是对于你的问题,还有另一个概念,你可能需要研究:面向方面的编程。

在.NET中,有一些很好的框架可用于执行面向方面的编程,包括Castle,LinFu和Microsoft的策略注入应用程序块。事实上,一些控制反转容器在其中也具有一些面向方面的特征。

这些概念和工具有助于使诸如日志记录等问题在代码噪声方面处于后台,并能自动处理。

相关文章

什么是设计模式一套被反复使用、多数人知晓的、经过分类编目...
单一职责原则定义(Single Responsibility Principle,SRP)...
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强...
适配器模式将一个类的接口转换成客户期望的另一个接口,使得...
策略模式定义了一系列算法族,并封装在类中,它们之间可以互...
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,...