依赖注入(DI)原理与三种实现方式详解-育师

1. 依赖注入的本质与价值

第一次接触依赖注入(Dependency Injection)这个概念时，我正面临一个典型的代码维护难题。项目中充斥着这样的代码：

public class OrderService { private readonly ILogger _logger = new FileLogger(); private readonly IEmailService _emailService = new SmtpEmailService(); public void ProcessOrder(Order order) { _logger.Log("Processing order..."); // 业务逻辑 _emailService.SendConfirmation(order); } }

这种紧耦合的代码带来三个致命问题：难以单元测试（因为直接依赖具体实现）、难以替换依赖项（需要修改每个实例化处）、违反单一职责原则（类需要关心依赖的创建）。依赖注入正是为解决这些问题而生。

2. 三种经典依赖注入方式详解

2.1 构造函数注入（最推荐方式）

这是我在实际项目中最常使用的方式，也是大多数DI容器默认支持的注入方式：

public class OrderService { private readonly ILogger _logger; private readonly IEmailService _emailService; // 依赖通过构造函数明确声明 public OrderService(ILogger logger, IEmailService emailService) { _logger = logger; _emailService = emailService; } public void ProcessOrder(Order order) { _logger.Log("Processing order..."); _emailService.SendConfirmation(order); } }

关键优势：依赖关系显式声明，强制要求调用方提供必要依赖，编译时即可发现缺失依赖。这也是为什么我强烈推荐将其作为默认选择。

2.2 属性注入（特定场景使用）

适用于可选依赖或后期绑定场景，在ASP.NET WebForms等老旧技术栈中较常见：

public class ReportGenerator { // 通过属性注入（通常配合[Inject]特性） public IDataFormatter Formatter { get; set; } public string Generate() { return Formatter?.Format(GetData()) ?? "No formatter available"; } }

使用陷阱：属性注入会隐藏依赖关系，可能引发NullReferenceException。我的经验法则是：只有当依赖确实是可选的时候才使用这种方式。

2.3 方法注入（最灵活但最不常用）

适用于每次调用可能需要不同实现的场景，在策略模式实现中很实用：

public class PaymentProcessor { public void Process(Payment payment, IPaymentValidator validator) { if (validator.IsValid(payment)) { // 处理支付 } } }

3. 现代DI容器的实战应用

3.1 .NET Core中的内置DI容器

以ASP.NET Core为例，典型的配置方式：

// Startup.cs public void ConfigureServices(IServiceCollection services) { // 瞬态生命周期（每次请求新实例） services.AddTransient<IEmailService, SmtpEmailService>(); // 作用域生命周期（同一请求内共享实例） services.AddScoped<IOrderRepository, SqlOrderRepository>(); // 单例生命周期（全局共享实例） services.AddSingleton<ILogger, FileLogger>(); }

生命周期选择是DI容器的核心知识点：

瞬态：轻量级无状态服务
作用域：需要请求上下文的服务（如DbContext）
单例：全局共享的配置或缓存服务

3.2 高级注册技巧

// 条件注册 services.AddSingleton<ICache>(provider => { return Environment.IsDevelopment() ? new MemoryCache() : new RedisCache(); }); // 多实现注册 services.AddTransient<IPaymentMethod, CreditCardPayment>(); services.AddTransient<IPaymentMethod, PayPalPayment>(); services.AddTransient<IPaymentMethod, CryptoPayment>(); // 解析时获取所有实现 var payments = services.GetServices<IPaymentMethod>();

4. 典型问题与解决方案

4.1 循环依赖问题

当ClassA依赖ClassB，ClassB又依赖ClassA时：

// 错误示例 public class ServiceA(ServiceB b) { /*...*/ } public class ServiceB(ServiceA a) { /*...*/ }

解决方案：

重构提取公共逻辑到第三个类
将其中一个依赖改为方法注入
使用Lazy 延迟初始化

4.2 过度注入问题

当构造函数参数超过5个时（俗称"构造函数污染"），表明类可能违反单一职责原则：

// 代码异味 public class OrderService( ILogger logger, IEmailService email, IInventoryService inventory, IPaymentGateway payment, IShippingService shipping, IDiscountCalculator discount) { //... }

重构方案：

使用外观模式封装相关依赖
应用领域驱动设计，拆分聚合根

4.3 测试中的妙用

依赖注入使单元测试变得简单：

[Test] public void ProcessOrder_Should_Send_Email() { // 创建mock var mockEmail = new Mock<IEmailService>(); var service = new OrderService(new NullLogger(), mockEmail.Object); // 执行测试 service.ProcessOrder(new Order()); // 验证行为 mockEmail.Verify(x => x.SendConfirmation(It.IsAny<Order>()), Times.Once); }