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();
作用域（Scoped）服务： 在每次客户端请求（HTTP请求）的生命周期内，只创建一次实例。在同一个请求中，无论多少次请求该服务，都会得到同一个实例。这非常适合处理请求相关的状态，比如数据库上下文。
public interface IMyScopedService{ string GetId();}public class MyScopedService : IMyScopedService{ private readonly Guid _id = Guid.NewGuid(); public string GetId() => _id.ToString();}// 注册方式services.AddScoped();
单例（Singleton）服务： 在应用程序的整个生命周期内，只创建一次实例。所有请求都会共享这一个实例。这适用于需要全局共享状态或资源的服务，但要特别注意线程安全问题。
public interface IMySingletonService{ string GetId();}public class MySingletonService : IMySingletonService{ private readonly Guid _id = Guid.NewGuid(); public string GetId() => _id.ToString();}// 注册方式services.AddSingleton();// 也可以直接注册一个已存在的实例// services.AddSingleton(new MySingletonService());
注册完成后，你就可以在你的控制器、中间件、视图组件等地方，通过构造函数注入的方式来使用这些服务了。DI容器会负责解析并提供正确的实例。
为什么ASP.NET Core如此强调依赖注入的重要性？
说实话，刚接触DI的时候，我个人觉得有点绕，多了一层抽象，感觉没直接
new
来得痛快。但一旦深入理解，你会发现它带来的好处是实实在在的，远超初期学习的成本。ASP.NET Core之所以把DI作为核心特性，主要原因在于它能够极大地提升代码的可维护性、可测试性、可扩展性。
首先是解耦。传统的开发方式，一个类可能直接依赖于另一个具体的类，导致它们之间紧密耦合。一旦被依赖的类发生变化，依赖它的类也可能需要修改。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的生命周期，这可能会引发意想不到的行为。
单例（Singleton）：这个生命周期需要你特别谨慎。它适用于全局共享、昂贵初始化、或者需要保持全局状态的服务。比如一个配置读取器、一个缓存管理器、一个日志服务。它们在整个应用程序生命周期中只需要一个实例。使用Singleton时，你必须确保服务是线程安全的，因为多个并发请求会共享同一个实例。任何对实例内部状态的修改都可能导致竞争条件和数据不一致。如果服务内部有可变状态，并且这个状态需要被多个请求独立维护，那绝对不能用Singleton。有时候，我也会用Singleton来注册一些第三方库的客户端，比如消息队列的连接工厂，因为这些连接通常是昂贵且可以复用的。
我的经验是，当你拿不准的时候，先考虑
Scoped
，它在Web应用中提供了一个很好的平衡点。如果服务是完全无状态的，且创建成本极低，可以考虑
Transient
。只有当你明确知道服务需要全局共享，且能保证线程安全时，才去用
Singleton
。
如何在ASP.NET Core中实现更复杂的依赖注册场景？
内置的DI容器虽然功能强大，但有时面对一些特殊的、更复杂的注册需求时，你可能会觉得它不够灵活。但别担心，ASP.NET Core提供了多种方式来应对这些挑战。
一个常见的场景是条件注册（Conditional Registration）。你可能希望根据某个配置值、环境（开发、测试、生产）或者其他运行时条件来注册不同的服务实现。虽然内置DI容器没有直接提供
When()
这样的语法糖，但我们可以通过工厂方法来间接实现：
// 假设我们有一个配置，决定使用哪个邮件服务var useSmtp = Configuration.GetValue("EmailSettings:UseSmtp");if (useSmtp){ services.AddScoped();}else{ services.AddScoped();}
这种方式直观且有效。
另一个是动态注册或者批量注册。当你有大量服务需要注册，并且它们遵循某种命名约定或接口模式时，手动一个个
AddScoped
会非常繁琐。我们可以利用反射来扫描程序集并自动注册：
// 假设所有实现IMyService接口的类都需要注册为Scopedservices.Scan(scan => scan .FromCallingAssembly() // 或者FromAssemblies(typeof(SomeClassInAssembly).Assembly) .AddClasses(classes => classes.AssignableTo()) .AsImplementedInterfaces() .WithScopedLifetime());
这里我用了
Scrutor
这个流行的第三方库，它极大地增强了ASP.NET Core内置DI容器的扫描和批量注册能力。它不是内置的，但非常常用，因为它能让你的
ConfigureServices
代码变得更简洁、更智能。
还有一种情况是多实现注册（Multiple Implementations）。当你有一个接口，但有多个不同的实现，并且你希望在运行时根据上下文选择注入哪一个。例如，你可能有一个
INotificationSender
接口，但有
EmailSender
和
SmsSender
两个实现。
services.AddScoped();services.AddScoped();
如果你直接注入
INotificationSender
，DI容器会默认注入最后一个注册的实现（在这里是
SmsSender
）。如果你需要同时获取所有实现，可以注入
IEnumerable
：
public class MyService{ private readonly IEnumerable _senders; public MyService(IEnumerable 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(), "sms" => _serviceProvider.GetRequiredService(), _ => throw new ArgumentException($"Unknown sender type: {type}") }; }}// 注册具体的实现和工厂services.AddScoped(); // 注意这里是具体的实现类，而不是接口services.AddScoped();services.AddScoped();// 使用时注入工厂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中的依赖注入容器是什么？如何注册服务？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439276.html
微信扫一扫 
支付宝扫一扫 
