答案是依赖注入通过解耦对象创建与使用，提升代码可维护性、可测试性和灵活性。在C#中，通过接口定义抽象，于Program.cs或Startup.cs中注册服务生命周期（Transient/Scoped/Singleton），并利用构造函数注入实现依赖，优先避免属性或方法注入，同时防止Service Locator反模式、过度注入及生命周期错配，确保高内聚低耦合。
C#中的依赖注入（Dependency Injection，简称DI）是一种设计模式，它将对象之间依赖关系的创建和管理从对象内部解耦出来，转交给外部的容器或框架来处理。简单来说，就是当一个对象需要另一个对象的功能时，它不再自己去创建或查找那个对象，而是声明自己需要什么，然后由外部“喂给”它。这使得代码模块化程度更高，更易于测试和维护。
在C#项目中配置依赖注入，尤其是在.NET Core/.NET 5+ 应用中，通常非常直接，因为框架内置了DI容器。以下是一个常见的配置流程：
定义接口和实现： 我们总是倾向于依赖抽象（接口），而不是具体的实现。
// 1. 定义一个接口
public interface IMessageService
{
string GetMessage();
}
// 2. 实现这个接口
public class EmailService : IMessageService
{
public string GetMessage()
{
return "Hello from EmailService!";
}
}
public class SmsService : IMessageService
{
public string GetMessage()
{
return "Hello from SmsService!";
}
}在DI容器中注册服务： 这通常发生在应用程序的启动配置阶段，比如在
Program.cs
Startup.cs
IMessageService
EmailService
// Program.cs (Minimal API example)
var builder = WebApplication.CreateBuilder(args);
// 注册服务
// AddScoped: 每个请求创建一个实例
// AddSingleton: 应用程序生命周期内只创建一个实例
// AddTransient: 每次请求都创建一个新的实例
builder.Services.AddScoped<IMessageService, EmailService>();
// 或者如果你想切换实现，只需要改这里
// builder.Services.AddScoped<IMessageService, SmsService>();
var app = builder.Build();
// ... 其他配置 ...
app.MapGet("/message", (IMessageService messageService) =>
{
return messageService.GetMessage();
});
app.Run();在ASP.NET Core MVC/Web API项目中，你会在控制器中通过构造函数注入：
public class HomeController : Controller
{
private readonly IMessageService _messageService;
// 构造函数注入：DI容器会自动提供IMessageService的实例
public HomeController(IMessageService messageService)
{
_messageService = messageService;
}
public IActionResult Index()
{
ViewBag.Message = _messageService.GetMessage();
return View();
}
}解析服务： 一旦服务注册完成，当你的类（如控制器、中间件等）声明需要某个接口时，DI容器就会自动找到对应的实现并将其注入。你几乎不需要手动去“解析”服务，这是DI容器为你做的核心工作。当然，在某些特殊场景下（比如在非DI管理的类中需要获取服务），你也可以通过
IServiceProvider
我刚开始接触DI的时候，坦白说，觉得有点绕，引入接口、注册服务，感觉一下子多了好多代码。但一旦理解了它真正解决的问题，就再也回不去了。核心原因在于它极大地提升了代码的可维护性、可测试性和灵活性。
想象一下，如果你没有DI，一个类直接依赖于另一个具体实现类，比如
OrderProcessor
new EmailSender()
OrderProcessor
EmailSender
SmsSender
EmailSender
OrderProcessor
有了DI，
OrderProcessor
IMessageSender
EmailSender
SmsSender
IMessageSender
IMessageSender
EmailSender
IMessageSender
SmsSender
OrderProcessor
IMessageSender
在C#中，我们主要通过三种方式来实现依赖注入，每种方式都有其适用场景和一些约定俗成：
构造函数注入 (Constructor Injection) 这是最常见、也是最推荐的方式。顾名思义，你通过类的构造函数来声明它所依赖的服务。
public class MyService
{
private readonly IDependency _dependency;
public MyService(IDependency dependency) // 依赖通过构造函数传入
{
_dependency = dependency;
}
public void DoSomething()
{
_dependency.Execute();
}
}适用场景：
readonly
属性注入 (Property Injection) 也称为Setter注入。在这种方式下，依赖通过公共属性（setter方法）注入到对象中。
public class MyService
{
public IDependency Dependency { get; set; } // 依赖通过公共属性传入
public void DoSomething()
{
// 需要检查Dependency是否为null，因为它是可选的
Dependency?.Execute();
}
}适用场景：
缺点： 依赖不是强制的，你可能需要在代码中手动检查依赖是否为null，这增加了复杂性。
方法注入 (Method Injection) 这种方式下，依赖作为参数传递给类中的某个方法，而不是在对象创建时注入。
public class MyService
{
public void DoSomething(IDependency dependency) // 依赖作为方法参数传入
{
dependency.Execute();
}
}适用场景：
ILogger
ILogger
ILogger
缺点： 如果一个方法需要很多依赖，其签名会变得很长，可读性下降。它也可能暗示这个方法承担了过多的职责。
通常，我们应该优先选择构造函数注入。它强制了依赖的存在，并使类的依赖关系一目了然。属性注入和方法注入则适用于更具体、更边缘的场景。
我在实际项目中，也踩过不少DI的坑，有些问题可能当时觉得很小，但随着项目复杂度的增加，会变得非常棘手。
Service Locator 反模式： 这是最常见也最危险的“坑”。你可能觉得，每次都通过构造函数注入太麻烦了，或者在某些静态方法里不好获取依赖，于是就搞了一个
ServiceLocator.Resolve<IMyService>()
// 这是一个反模式的例子，请避免！
public class AnotherService
{
public void Process()
{
// 手动从全局Service Locator中解析依赖
var myService = ServiceLocator.Current.GetService<IMyService>();
myService.DoSomething();
}
}问题： 这样做虽然方便，但实际上又把依赖的查找和管理权交回给了类内部，破坏了DI的初衷。你的类不再声明它需要什么，而是主动去“拉取”依赖。这使得类的依赖关系变得不透明，难以测试，也失去了DI带来的解耦优势。你无法一眼看出一个类到底依赖了哪些服务。
最佳实践： 坚持构造函数注入。如果确实需要在非DI管理的区域获取服务，考虑重构代码结构，或者在最接近DI容器的边缘（如ASP.NET Core的
Program.cs
Startup.cs
过度注入 (Constructor Over-injection)： 一个类的构造函数参数过多（比如超过5-7个），这通常意味着这个类承担了过多的职责（违反了单一职责原则）。
public class GodService
{
public GodService(IDep1 dep1, IDep2 dep2, IDep3 dep3, IDep4 dep4, IDep5 dep5, IDep6 dep6)
{ /* ... */ }
}问题： 这样的类难以理解、难以测试、难以维护。每次修改一个功能，都可能影响到其他不相关的部分。
最佳实践： 重构你的类。将大的类拆分成更小、职责更单一的类。引入外观模式（Facade）或组合模式，将多个小服务组合成一个更高层级的服务，然后注入这个高层级服务。
生命周期管理不当： DI容器中的服务有不同的生命周期（Transient, Scoped, Singleton）。错误地混合使用它们会导致内存泄漏、数据不一致或运行时错误。
常见问题： 在一个单例服务中注入一个作用域或瞬时服务。单例服务只被创建一次，它会“捕获”它所依赖的瞬时或作用域服务的第一个实例。这意味着，即使外部作用域结束，单例服务仍然持有那个旧的实例，导致后续请求无法获得新的瞬时/作用域实例。我记得有一次，因为对Scoped和Singleton理解不深，在一个单例服务里注入了一个Scoped的数据库上下文，导致了奇怪的并发和数据更新问题，排查了很久才发现是生命周期管理出了错。
最佳实践： 始终确保你的依赖的生命周期不短于依赖它的对象的生命周期。如果一个单例服务确实需要一个作用域或瞬时服务，考虑使用工厂模式，或者注入
IServiceProvider
注册具体类型而不是接口： 虽然DI容器允许你直接注册具体类型（
builder.Services.AddScoped<MyConcreteService>();
问题： 直接依赖具体类型会降低代码的灵活性和可测试性。如果你想替换
MyConcreteService
最佳实践： 尽可能地依赖抽象（接口）。
builder.Services.AddScoped<IMyService, MyConcreteService>();
IMyService
遵循这些实践，可以帮助你更好地利用依赖注入的强大功能，构建出更健壮、更灵活、更易于维护的C#应用程序。
以上就是C#的依赖注入是什么？如何在项目中配置？的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
274
收藏
