依赖注入 - 何时在 Web 应用程序中使用单例范围答案

【问题标题】：Dependency Injection - When to use a Singleton scope in a Web Application依赖注入 - 何时在 Web 应用程序中使用单例范围
【发布时间】：2018-04-16 20:00:35
【问题描述】：

在我的 .NET Web APIv2 项目中，我发现自己将所有注入服务的范围标记为 Singleton。

我正在使用Simple Injector DI 框架（这对我的具体问题并不重要）。

这是一个简化的例子：

public class SqlConnectionFactory : IDbConnectionFactory
{
    public async Task<SqlConnection> GetOpenSqlConnectionAsync()
    {
        var connection = new SqlConnection("connstring");

        await connection.OpenAsync();

        return connection;
    }
}


public class UserService : IUserService
{
    private IDbConnectionFactory DbConnectionFactory { get; set; }

    public UserService(IDbConnectionFactory dbConnectionFactory)
    {
        DbConnectionFactory = dbConnectionFactory;
    }

    public async Task AddAsync(AddUserDto data)
    {
        using (SqlConnection connection = await DbConnectionFactory.GetOpenSqlConnectionAsync())
        {
            // Create a glorious SqlCommand...
            await cmd.ExecuteNonQueryAsync();
        }
    }
}

我的一些其他服务包括一些加密类，它们不包含任何状态，并且很容易成为静态类。

这是简单注入代码，只是为了完成：

        var container = new Container();

        container.Register<IDbConnectionFactory, SqlConnectionFactory>(Lifestyle.Singleton);
        container.Register<IUserService, UserService>(Lifestyle.Singleton);

根据我创建数据库连接的方式，在我看来单例对于我的SqlConnectionFactory 类和我的UserService 类都很好，但如果我错了，请纠正我。

这让我问，你什么时候（或者你不会）使用单例范围来注入服务？如果你可以使用单例，你为什么不呢？不必为每个 Web 请求线程或方法的入口（Transient）实例化一个新实例，这难道不是性能优势吗？

【问题讨论】：

这个问题的答案其实比较复杂，但我个人倾向于基于单例组件来制作我的完整对象图。您希望注册为 Scoped 的所有可能的运行时数据，并且不应在构造对象图时创建。
相关：stackoverflow.com/a/32033648/264697
有趣的问题

标签： .net asp.net-web-api dependency-injection inversion-of-control simple-injector

【解决方案1】：

作为一般规则，对线程安全类使用 Singleton 生命周期。如果单个实例也可以完成这项工作，那么就没有理由一直创建新实例。但是，您也需要避免使用Captive Dependencies。

在 OP 的情况下，在我看来所有类都是无状态的（因此是线程安全的），所以单例生命周期对我来说看起来不错。

使用 DI 容器时可能很难发现生命周期不匹配，但会变得很多 easier to detect when using Pure DI。这是我更喜欢Pure DI 的众多原因之一。

【讨论】：