依赖注入通过外部注入对象实现解耦，提升代码可测试性与维护性。示例中UserService不再自行创建UserDataAccess，而是通过构造函数接收IUserDataAccess实现，.NET内置容器在Program.cs中注册服务生命周期（Scoped/Singleton/Transient），运行时自动注入实例，测试时可替换为Mock对象，避免硬编码依赖，统一管理对象创建，降低耦合度。
依赖注入（Dependency Injection，简称 DI）是 C# 和 .NET 开发中一个非常重要的设计模式。它帮助我们写出更松耦合、更容易测试和维护的代码。如果你刚接触这个概念，可能会觉得抽象，但其实它的核心思想很简单：不要自己创建对象，而是让外部系统把需要的对象“送进来”。
什么是依赖？
在面向对象编程中，一个类经常需要使用另一个类的功能。比如，有一个 UserService 类需要访问数据库，它可能依赖于一个 UserDataAccess 类。这种“需要别人帮忙完成工作”的关系就是“依赖”。
示例：
假设你有一个用户服务类：
public class UserService
{
private UserDataAccess _dataAccess;
public UserService()
{
_dataAccess = new UserDataAccess(); // 手动创建依赖
}
public string GetUser(int id)
{
return _dataAccess.GetUserById(id);
}}
这里的问题是：UserService 自己创建了 UserDataAccess，导致两者紧紧绑在一起。如果将来想换成 Mock 数据或不同的实现，就必须修改代码 —— 这不利于测试和扩展。
依赖注入的核心思想
DI 的基本思路是：把依赖项从外部“注入”进来，而不是在类内部自己 new 出来。最常见的方式是通过构造函数传入。
改写上面的例子：
public class UserService
{
private readonly IUserDataAccess _dataAccess;
public UserService(IUserDataAccess dataAccess) // 依赖通过构造函数传入
{
_dataAccess = dataAccess;
}
public string GetUser(int id)
{
return _dataAccess.GetUserById(id);
}}
现在，UserService 不关心具体是谁提供数据访问功能，只要对方符合 IUserDataAccess 接口就行。这就实现了“解耦”。
.NET 中的内置 DI 容器
.NET Core 及以后版本内置了依赖注入容器，可以在程序启动时注册服务，并自动把它们注入到需要的地方。
步骤如下：
- 定义接口和实现
- 在 Program.cs 或 Startup.cs 中注册服务
- 在类中通过构造函数接收依赖
完整示例：
// 1. 定义接口
public interface IUserDataAccess
{
string GetUserById(int id);
}
// 2. 实现接口
public class UserDataAccess : IUserDataAccess
{
public string GetUserById(int id)
{
return $"User {id} from database";
}
}
// 3. 使用依赖的服务
public class UserService
{
private readonly IUserDataAccess _dataAccess;
public UserService(IUserDataAccess dataAccess)
{
_dataAccess = dataAccess;
}
public string GetUser(int id)
{
return _dataAccess.GetUserById(id);
}}
在 Program.cs（.NET 6+）中注册服务：
var builder = WebApplication.CreateBuilder(args);
// 注册服务：告诉容器 IUserDataAccess 应该用 UserDataAccess 来实例化
builder.Services.AddScoped();
builder.Services.AddScoped();
var app = builder.Build();
// 示例：在 Minimal API 中使用
app.MapGet("/user/{id}", (int id, UserService userService) =>
{
return userService.GetUser(id);
});
app.Run();
当你访问 /user/1 时，.NET 会自动创建 UserService 实例，并把已注册的 IUserDataAccess 实现注入进去。
三种常见的服务生命周期
注册服务时，你需要选择它的生命周期：
- Scoped：每次 HTTP 请求创建一次（适用于 Web 应用）
- Singleton：整个程序运行期间只创建一次
- Transient：每次请求都创建新实例
一般情况下：
- 数据访问类用 Scoped
- 工具类或无状态服务可用 Singleton
- 轻量级、有状态的临时对象可用 Transient
为什么使用 DI？好处有哪些？
- 易于测试：你可以注入 Mock 对象进行单元测试
- 解耦代码：类之间不再硬编码依赖关系
- 便于维护：更换实现时只需修改注册代码，无需改动业务类
- 统一管理对象创建：避免手动 new 导致的资源浪费或错误
举个测试的例子：
// 测试时可以注入一个假的数据访问层
public class MockUserDataAccess : IUserDataAccess
{
public string GetUserById(int id) => $"Mock User {id}";
}
// 单元测试中
var mockDataAccess = new MockUserDataAccess();
var userService = new UserService(mockDataAccess); // 注入模拟对象
var result = userService.GetUser(1);
Console.WriteLine(result); // 输出: Mock User 1
这样不需要真实数据库就能测试逻辑。
基本上就这些。依赖注入不是魔法，它只是一个帮你更好地组织代码的工具。刚开始可能会觉得多写了不少接口和注册代码，但随着项目变大，你会发现它带来的清晰结构和灵活性非常值得。
