Why should you care?

ShopNest may want one in-process cache coordinator — but a careless singleton becomes a hidden global that ruins tests.

See it live — copy this example

Paste into a C# console or class library project and run dotnet run.

public sealed class ShopNestConfig
{
    private static readonly Lazy<ShopNestConfig> _lazy =
        new(() => new ShopNestConfig());
    public static ShopNestConfig Instance => _lazy.Value;
    public string ConnectionName { get; init; } = "ShopNest";
    private ShopNestConfig() { }
}

Console.WriteLine(ShopNestConfig.Instance.ConnectionName);

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• Lazy creates the instance once in a thread-safe way.
• The private constructor blocks new ShopNestConfig().
• Prefer services.AddSingleton() in ASP.NET Core for testability.

Practice next

1. Create a console app and paste the example.
2. Print Instance twice and confirm the same values.
3. Try new ShopNestConfig() and see it fails to compile.
4. Add a second property and read it from Instance.
5. Replace with DI AddSingleton and resolve twice.

Remember

One instance, controlled access. Lazy or DI singleton lifetime. Avoid hidden globals when DI works.

ShopNest process-wide feature flags

A small in-memory flag reader registered as singleton.

Outcome: All requests see the same flag snapshot without a static mess.