将记录器作为单例是一个好习惯吗？

我习惯将记录器传递给构造函数，例如：

public class OrderService : IOrderService {
     public OrderService(ILogger logger) {
     }
}

但这很烦人，因此我已经将它用作属性一段时间了：

private ILogger logger = NullLogger.Instance;
public ILogger Logger
{
    get { return logger; }
    set { logger = value; }
}

这也很烦人-它并不干燥，我需要在每节课中重复。我可以使用基类，但是再说一次-我使用的是Form类，因此需要FormBase等。所以我认为，暴露ILogger的单例将带来什么负面影响，所以一个人就会知道在哪里获取记录器：

    Infrastructure.Logger.Info("blabla");

更新：正如Merlyn正确注意到的那样，我应该提到，在第一和第二个示例中，我正在使用DI。

这也变得很烦人-它不是干的

确实如此。但是，对于跨领域的问题您无能为力，这种问题遍及您的每种类型。您必须在各处使用记录器，因此必须在这些类型上具有该属性。

因此，让我们看看我们能做些什么。

辛格尔顿

单身人士太可怕了<flame-suit-on>。

我建议像第二个示例一样，坚持使用属性注入。这是您不诉诸魔术即可做到的最佳因素。具有显式依赖关系比通过单例隐藏它更好。

但是，如果单身人士为您节省了大量时间，包括您将不得不做的所有重构工作（水晶球时间！），我想您也许可以与他们共处。如果曾经有一个Singleton的用途，可能就是这样。记住的成本，如果你曾经想改变你的思想会约高，因为它得到。

如果你这样做，看看别人的答案使用的Registry模式（见说明书），而那些注册（可复位）单工厂，而不是一个单独的记录器实例。

还有其他选择也可以在不做太多妥协的情况下同样有效，因此您应该先检查一下它们。

Visual Studio代码段

您可以使用Visual Studio代码段来加快重复代码的输入速度。您将可以输入类似loggertab，并且代码会为您神奇地出现。

使用AOP进行干燥

您可以通过使用诸如PostSharp之类的面向方面的编程（AOP）框架来自动生成其中的一些属性注入代码。

完成后，可能看起来像这样：

[InjectedLogger]
public ILogger Logger { get; set; }

您还可以使用他们的方法跟踪示例代码来自动跟踪方法的入口和出口代码，这可能消除了将某些记录器属性全部添加在一起的需要。您可以在类级别或命名空间范围内应用属性：

[Trace]
public class MyClass
{
    // ...
}

// or

#if DEBUG
[assembly: Trace( AttributeTargetTypes = "MyNamespace.*",
    AttributeTargetTypeAttributes = MulticastAttributes.Public,
    AttributeTargetMemberAttributes = MulticastAttributes.Public )]
#endif

我在自己的依赖项注入容器中放入了一个logger实例，然后将其注入到需要一个类的类中。

好问题。我相信大多数项目记录器都是单例的。

我想到了一些想法：

• 使用ServiceLocator（或其他依赖项注入）容器，如果您已经使用过的话），允许您在服务/类之间共享记录器，这样您就可以实例化记录器甚至多个不同的记录器，并通过ServiceLocator进行共享，这显然是单例，某种控制反转。这种方法为您提供了记录器实例化和初始化过程的更多灵活性。
• 如果你需要记录几乎无处不在-实现扩展方法Object类型，这样每一类将能够调用记录器的方法，例如LogInfo()，LogDebug()，LogError()

单身人士是个好主意。更好的主意是使用注册表模式，该模式对实例化提供了更多控制。我认为单例模式过于接近全局变量。通过注册表处理对象的创建或重用，将来可以更改实例化规则。

注册表本身可以是一个静态类，以提供简单的语法来访问日志：

Registry.Logger.Info("blabla");

简单的单例并不是一个好主意。这使得很难更换记录仪。我倾向于为记录器使用过滤器（某些“嘈杂的”类可能仅记录警告/错误）。

我将单例模式与代理模式结合用于记录器工厂：

public class LogFactory
{
    private static LogFactory _instance;

    public static void Assign(LogFactory instance)
    {
        _instance = instance;
    }

    public static LogFactory Instance
    {
        get { _instance ?? (_instance = new LogFactory()); }
    }

    public virtual ILogger GetLogger<T>()
    {
        return new SystemDebugLogger();
    }
}

这使我无需更改任何代码即可创建aFilteringLogFactory或a SimpleFileLogFactory（因此符合Open / Closed原理）。

样品扩展

public class FilteredLogFactory : LogFactory
{
    public override ILogger GetLogger<T>()
    {
        if (typeof(ITextParser).IsAssignableFrom(typeof(T)))
            return new FilteredLogger(typeof(T));

        return new FileLogger(@"C:\Logs\MyApp.log");
    }
}

并使用新工厂

// and to use the new log factory (somewhere early in the application):
LogFactory.Assign(new FilteredLogFactory());

在您的班级中应记录以下内容：

public class MyUserService : IUserService
{
    ILogger _logger = LogFactory.Instance.GetLogger<MyUserService>();

    public void SomeMethod()
    {
        _logger.Debug("Welcome world!");
    }
}

.NET中有一本书“依赖注入”。根据需要，您应该使用拦截。

本书中的图表有助于确定是否使用构造函数注入，属性注入，方法注入，环境上下文，拦截。

这就是使用此图的原因之一：

1. 您是否有依赖关系？- 需要它
2. 是跨领域的关注点吗？-是的
3. 您需要答案吗？-没有

使用拦截

我个人认为最简单的另一种解决方案是使用静态Logger类。您可以从任何类方法中调用它，而无需更改类，例如添加属性注入等。它非常简单易用。

Logger::initialize ("filename.log", Logger::LEVEL_ERROR); // only need to be called once in your application

Logger::log ("my error message", Logger::LEVEL_ERROR); // to be used in every method where needed

如果您想寻找一个很好的日志记录解决方案，建议您使用python来查看google app引擎，其中日志记录非常简单import logging，然后就可以做到，logging.debug("my message")或者logging.info("my message")实际上可以使日志尽可能简单。

Java没有一个很好的日志记录解决方案，即应避免使用log4j，因为它实际上迫使您使用单例，这在这里回答是“可怕的”，并且我在尝试使一次日志记录输出相同的日志记录语句方面经历了可怕的经历。当我怀疑重复记录的原因是我在同一虚拟机的两个类加载器中有一个Singleton的记录对象时（！）

不好意思，我对C＃并不是那么专一，但是从我看到的C＃解决方案来看，Java看上去与Java类似，因为我们有log4j，也应该将其做成单例。

这就是为什么我真的很喜欢GAE / python解决方案，它是如此简单，而且您不必为此担心类加载器，获取双记录语句或任何设计模式。

我希望其中一些信息与您相关，并且希望您看一看我建议的日志记录解决方案，而不是因为我不可能欺负Singleton导致多少问题，因为它必须在多个类加载器中实例化。