ASP.NET Core中的依赖注入容器是什么？如何注册服务？

ASP.NET Core依赖注入容器通过IServiceCollection在ConfigureServices中注册服务，支持Transient、Scoped、Singleton三种生命周期，实现解耦、提升可测试性与可扩展性，合理选择生命周期并结合工厂模式或第三方库可应对复杂场景。

ASP.NET Core中的依赖注入（DI）容器，说白了，就是框架提供的一个工具，用来管理你应用程序中各个组件（也就是服务）的创建和生命周期。它能自动帮你把一个服务需要的其他服务“喂”给它，省去了我们手动new来new去的麻烦。至于如何注册服务，核心就是在

Startup.cs

Program.cs

ConfigureServices

IServiceCollection

ASP.NET Core内置的依赖注入容器是一个轻量级且高效的解决方案，它极大地简化了应用程序的架构设计和维护。想象一下，如果没有DI，你的每个类可能都需要自己去创建它所依赖的对象，这会导致代码高度耦合，难以测试和修改。DI容器通过将对象的创建和管理职责从应用程序代码中分离出来，使得组件之间保持松散耦合。

在ASP.NET Core中，服务注册主要通过

IServiceCollection

• 瞬时（Transient）服务： 每次请求该服务时，都会创建一个新的实例。这适用于轻量级、无状态的服务。

  public interface IMyTransientService
  {
      string GetId();
  }
  
  public class MyTransientService : IMyTransientService
  {
      private readonly Guid _id = Guid.NewGuid();
      public string GetId() => _id.ToString();
  }
  
  // 注册方式
  services.AddTransient<IMyTransientService, MyTransientService>();

  登录后复制

• 作用域（Scoped）服务： 在每次客户端请求（HTTP请求）的生命周期内，只创建一次实例。在同一个请求中，无论多少次请求该服务，都会得到同一个实例。这非常适合处理请求相关的状态，比如数据库上下文。

  public interface IMyScopedService
  {
      string GetId();
  }
  
  public class MyScopedService : IMyScopedService
  {
      private readonly Guid _id = Guid.NewGuid();
      public string GetId() => _id.ToString();
  }
  
  // 注册方式
  services.AddScoped<IMyScopedService, MyScopedService>();

  登录后复制

• 单例（Singleton）服务： 在应用程序的整个生命周期内，只创建一次实例。所有请求都会共享这一个实例。这适用于需要全局共享状态或资源的服务，但要特别注意线程安全问题。

  public interface IMySingletonService
  {
      string GetId();
  }
  
  public class MySingletonService : IMySingletonService
  {
      private readonly Guid _id = Guid.NewGuid();
      public string GetId() => _id.ToString();
  }
  
  // 注册方式
  services.AddSingleton<IMySingletonService, MySingletonService>();
  // 也可以直接注册一个已存在的实例
  // services.AddSingleton<IMySingletonService>(new MySingletonService());

  登录后复制

注册完成后，你就可以在你的控制器、中间件、视图组件等地方，通过构造函数注入的方式来使用这些服务了。DI容器会负责解析并提供正确的实例。

为什么ASP.NET Core如此强调依赖注入的重要性？

说实话，刚接触DI的时候，我个人觉得有点绕，多了一层抽象，感觉没直接

new

首先是解耦。传统的开发方式，一个类可能直接依赖于另一个具体的类，导致它们之间紧密耦合。一旦被依赖的类发生变化，依赖它的类也可能需要修改。DI通过接口和抽象来打破这种直接依赖，你的类只需要知道它需要一个

IMyService

MyServiceA

MyServiceB

其次是可测试性。这是DI最直观的优势之一。当你需要测试一个方法时，如果它依赖于复杂的外部服务（比如数据库、外部API），在没有DI的情况下，你可能需要启动整个环境或者编写复杂的模拟对象。有了DI，你可以轻松地用“模拟对象”（Mock）或“存根”（Stub）替换掉真实的依赖，只测试当前类的逻辑，而不用担心外部服务的影响。这让单元测试变得简单高效，是实现高质量代码的关键。

再者是可扩展性。当业务需求变化，需要替换某个服务实现时，如果你的代码是基于DI构建的，你只需要修改一处注册代码（比如从

MyServiceA

MyServiceB

在实际项目中，如何选择合适的生命周期（Transient, Scoped, Singleton）？

选择正确的服务生命周期是DI容器使用中的一个核心决策，它直接影响到应用程序的性能、资源消耗以及潜在的并发问题。这事儿没有绝对的公式，更多的是一种权衡和经验积累。

• 瞬时（Transient）：我通常会把那些无状态、轻量级、不包含任何可变数据的服务注册为瞬时。比如一个纯粹的计算器服务、一个数据格式转换器。每用一次就创建一个新的，用完就丢，简单干净。如果你不确定，通常从Transient开始是一个相对安全的默认选项，因为它的隔离性最好，不容易引发共享状态问题。但要注意，频繁创建和销毁对象会有轻微的性能开销，虽然对于大多数应用来说，这点开销微乎其微。

• 作用域（Scoped）：这是ASP.NET Core Web应用中最常用的生命周期之一，尤其适用于与HTTP请求生命周期绑定的服务。最典型的例子就是数据库上下文（如

  DbContext

  登录后复制
  ）。在一个HTTP请求处理期间，我们通常希望所有的数据库操作都使用同一个

  DbContext

  登录后复制
  实例，这样可以确保事务的一致性，避免不必要的数据加载。如果你的服务需要访问请求级别的上下文数据，或者需要在一个请求内保持状态一致，那么Scoped就是你的首选。需要注意的是，如果你在Scoped服务中注入了Singleton服务，那没问题；但如果在Singleton服务中注入了Scoped或Transient服务，就会出现“Captured Dependency”问题，导致Scoped/Transient服务实际上变成了Singleton的生命周期，这可能会引发意想不到的行为。
  

  讯飞智作-讯飞配音

  讯飞智作是一款集AI配音、虚拟人视频生成、PPT生成视频、虚拟人定制等多功能的AI音视频生产平台。已广泛应用于媒体、教育、短视频等领域。

  67

  查看详情

• 单例（Singleton）：这个生命周期需要你特别谨慎。它适用于全局共享、昂贵初始化、或者需要保持全局状态的服务。比如一个配置读取器、一个缓存管理器、一个日志服务。它们在整个应用程序生命周期中只需要一个实例。使用Singleton时，你必须确保服务是线程安全的，因为多个并发请求会共享同一个实例。任何对实例内部状态的修改都可能导致竞争条件和数据不一致。如果服务内部有可变状态，并且这个状态需要被多个请求独立维护，那绝对不能用Singleton。有时候，我也会用Singleton来注册一些第三方库的客户端，比如消息队列的连接工厂，因为这些连接通常是昂贵且可以复用的。

我的经验是，当你拿不准的时候，先考虑

Scoped

Transient

Singleton

如何在ASP.NET Core中实现更复杂的依赖注册场景？

内置的DI容器虽然功能强大，但有时面对一些特殊的、更复杂的注册需求时，你可能会觉得它不够灵活。但别担心，ASP.NET Core提供了多种方式来应对这些挑战。

一个常见的场景是条件注册（Conditional Registration）。你可能希望根据某个配置值、环境（开发、测试、生产）或者其他运行时条件来注册不同的服务实现。虽然内置DI容器没有直接提供

When()

// 假设我们有一个配置，决定使用哪个邮件服务
var useSmtp = Configuration.GetValue<bool>("EmailSettings:UseSmtp");

if (useSmtp)
{
    services.AddScoped<IEmailSender, SmtpEmailSender>();
}
else
{
    services.AddScoped<IEmailSender, MockEmailSender>();
}

这种方式直观且有效。

另一个是动态注册或者批量注册。当你有大量服务需要注册，并且它们遵循某种命名约定或接口模式时，手动一个个

AddScoped

// 假设所有实现IMyService接口的类都需要注册为Scoped
services.Scan(scan => scan
    .FromCallingAssembly() // 或者FromAssemblies(typeof(SomeClassInAssembly).Assembly)
    .AddClasses(classes => classes.AssignableTo<IMyService>())
    .AsImplementedInterfaces()
    .WithScopedLifetime());

这里我用了

Scrutor

ConfigureServices

还有一种情况是多实现注册（Multiple Implementations）。当你有一个接口，但有多个不同的实现，并且你希望在运行时根据上下文选择注入哪一个。例如，你可能有一个

INotificationSender

EmailSender

SmsSender

services.AddScoped<INotificationSender, EmailSender>();
services.AddScoped<INotificationSender, SmsSender>();

如果你直接注入

INotificationSender

SmsSender

IEnumerable<INotificationSender>

public class MyService
{
    private readonly IEnumerable<INotificationSender> _senders;

    public MyService(IEnumerable<INotificationSender> senders)
    {
        _senders = senders; // 这里会得到EmailSender和SmsSender的实例
    }
}

如果你需要根据某个键或条件来获取特定的实现，那内置容器就有点力不从心了。这时，你可以考虑使用工厂模式结合DI，或者引入像Autofac这样的第三方DI容器，它们通常提供更高级的功能，如命名服务注册（Named Registration）或更强大的条件解析能力。

例如，一个简单的工厂模式实现：

// 定义一个工厂接口
public interface INotificationSenderFactory
{
    INotificationSender GetSender(string type);
}

// 实现工厂
public class NotificationSenderFactory : INotificationSenderFactory
{
    private readonly IServiceProvider _serviceProvider; // 注入服务提供者

    public NotificationSenderFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public INotificationSender GetSender(string type)
    {
        return type switch
        {
            "email" => _serviceProvider.GetRequiredService<EmailSender>(),
            "sms" => _serviceProvider.GetRequiredService<SmsSender>(),
            _ => throw new ArgumentException($"Unknown sender type: {type}")
        };
    }
}

// 注册具体的实现和工厂
services.AddScoped<EmailSender>(); // 注意这里是具体的实现类，而不是接口
services.AddScoped<SmsSender>();
services.AddScoped<INotificationSenderFactory, NotificationSenderFactory>();

// 使用时注入工厂
public class MyController : ControllerBase
{
    private readonly INotificationSenderFactory _factory;

    public MyController(INotificationSenderFactory factory)
    {
        _factory = factory;
    }

    [HttpGet]
    public IActionResult SendNotification(string type)
    {
        var sender = _factory.GetSender(type);
        sender.Send("Hello from ASP.NET Core!");
        return Ok();
    }
}

这种方式虽然增加了代码量，但提供了极大的灵活性，能够处理各种复杂的运行时服务选择逻辑。记住，DI的目的是简化，而不是复杂化。选择最适合你当前需求和团队理解成本的方案才是最重要的。

以上就是ASP.NET Core中的依赖注入容器是什么？如何注册服务？的详细内容，更多请关注php中文网其它相关文章！