如何在采用单例模式的.NET类库中集成ILogger<T>抽象，并允许消费者注入自定义日志实现

Great question! Making your library logger-agnostic while keeping its singleton pattern is totally doable—you just need to adjust how the singleton gets initialized and accepts the logger dependency. Let’s walk through practical, maintainable approaches:

Approach 1: Lazy Initialization with Explicit Initialization Method #

Your current singleton is initialized immediately (via public static MyLibrary Instance { get; } = new MyLibrary();), which leaves no room to pass in an ILogger<T>. Switching to lazy initialization with a dedicated setup method lets consumers provide the logger upfront before using the singleton.

Here’s how to implement it:

public class MyLibrary
{
    private static MyLibrary _instance;
    private static readonly object _lock = new object();
    private readonly ILogger<MyLibrary> _logger;

    // Private constructor now accepts the logger
    private MyLibrary(ILogger<MyLibrary> logger)
    {
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
        // Your existing constructor logic here
    }

    public static MyLibrary Instance
    {
        get
        {
            if (_instance == null)
            {
                throw new InvalidOperationException(
                    "MyLibrary hasn't been initialized. Call Initialize() first with a valid ILogger<MyLibrary>.");
            }
            return _instance;
        }
    }

    public static void Initialize(ILogger<MyLibrary> logger)
    {
        lock (_lock)
        {
            if (_instance != null)
            {
                throw new InvalidOperationException("MyLibrary is already initialized.");
            }
            _instance = new MyLibrary(logger);
        }
    }
}

Pros: #

• Thread-safe: Uses double-check locking to prevent race conditions during initialization.
• Explicit: Forces consumers to set up the logger before using the library, avoiding silent failures from missing logs.
• Preserves singleton integrity: Only one instance is ever created.

Cons: #

• Requires consumers to add an initialization call (e.g., in their app startup code) before accessing Instance. You’ll want to document this clearly.

Approach 2: Default Null Logger + Late Injection #

If you want to maintain backward compatibility (so consumers don’t have to change existing code that uses MyLibrary.Instance directly), you can fall back to a NullLogger<T> by default and let consumers inject a real logger later.

using Microsoft.Extensions.Logging;
using System.Threading;

public class MyLibrary
{
    private static readonly MyLibrary _instance = new MyLibrary();
    private ILogger<MyLibrary> _logger = NullLogger<MyLibrary>.Instance;

    private MyLibrary()
    {
        // Existing constructor logic
    }

    public static MyLibrary Instance => _instance;

    // Thread-safe method to update the logger post-initialization
    public void SetLogger(ILogger<MyLibrary> logger)
    {
        if (logger == null) throw new ArgumentNullException(nameof(logger));
        Interlocked.Exchange(ref _logger, logger);
    }
}

Pros: #

• Backward-compatible: Consumers can keep using MyLibrary.Instance immediately without setup.
• Flexible: Loggers can be injected at any time (though ideally during app startup).

Cons: #

• Logs generated before SetLogger is called will be lost (since NullLogger discards them).
• Requires discipline from consumers to call SetLogger early to avoid missing logs.

Approach 3: Integrate with Dependency Injection (for DI-aware consumers) #

If most of your library’s users are using .NET’s built-in DI (like ASP.NET Core apps), you can let the DI container manage the singleton while still exposing the static Instance property for backward compatibility.

public class MyLibrary
{
    private static MyLibrary _instance;
    private readonly ILogger<MyLibrary> _logger;

    // Public constructor for DI injection
    public MyLibrary(ILogger<MyLibrary> logger)
    {
        _logger = logger ?? throw new ArgumentNullException(nameof(logger));
        // Ensure only one instance exists
        if (_instance != null)
        {
            throw new InvalidOperationException(
                "MyLibrary is already instantiated. Use dependency injection or the Instance property.");
        }
        _instance = this;
    }

    public static MyLibrary Instance
    {
        get
        {
            if (_instance == null)
            {
                throw new InvalidOperationException(
                    "MyLibrary hasn't been registered with dependency injection.");
            }
            return _instance;
        }
    }
}

Consumers would register it in their DI setup like this:

services.AddSingleton<MyLibrary>();

Pros: #

• Aligns with .NET best practices for dependency injection.
• Automatically injects the logger from the consumer’s configured logging provider.

Cons: #

• Doesn’t work well for consumers not using DI.
• The public constructor means you have to enforce singleton logic internally to prevent multiple instances.

Can You Do This Without Modifying the Singleton Pattern? #

Strictly speaking, no—your current singleton is initialized immediately with a parameterless private constructor, which gives no way to pass in an external ILogger<T> without breaking encapsulation. Hacky workarounds like using reflection to set a private logger field are not recommended (they’re fragile, violate encapsulation, and can break with future code changes).

The approaches above modify the singleton’s initialization logic but preserve its core purpose (ensuring only one instance exists) while adding support for logger injection.

内容的提问来源于stack exchange，提问作者OpticTygre