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.AddTransientIEmailService, SmtpEmailService(); // 作用域生命周期同一请求内共享实例 services.AddScopedIOrderRepository, SqlOrderRepository(); // 单例生命周期全局共享实例 services.AddSingletonILogger, FileLogger(); }生命周期选择是DI容器的核心知识点瞬态轻量级无状态服务作用域需要请求上下文的服务如DbContext单例全局共享的配置或缓存服务3.2 高级注册技巧// 条件注册 services.AddSingletonICache(provider { return Environment.IsDevelopment() ? new MemoryCache() : new RedisCache(); }); // 多实现注册 services.AddTransientIPaymentMethod, CreditCardPayment(); services.AddTransientIPaymentMethod, PayPalPayment(); services.AddTransientIPaymentMethod, CryptoPayment(); // 解析时获取所有实现 var payments services.GetServicesIPaymentMethod();4. 典型问题与解决方案4.1 循环依赖问题当ClassA依赖ClassBClassB又依赖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 MockIEmailService(); var service new OrderService(new NullLogger(), mockEmail.Object); // 执行测试 service.ProcessOrder(new Order()); // 验证行为 mockEmail.Verify(x x.SendConfirmation(It.IsAnyOrder()), Times.Once); }5. 我的实战经验总结经过多年使用DI的经验有几个关键心得值得分享构造函数注入作为默认选择除非有充分理由否则坚持使用构造函数注入。它使依赖关系最明确。避免服务定位器反模式不要滥用IServiceProvider.GetService()这相当于把DI容器当全局变量使用。注意生命周期管理特别是当注入Scoped服务到Singleton服务中时可能导致内存泄漏。分层注册原则基础设施层注册具体实现应用层注册接口映射这样更易于维护。配合接口隔离原则为每个服务定义精确的接口而不是一个大而全的接口。在最近的一个电商项目中我们通过合理应用DI原则使单元测试覆盖率从15%提升到了70%同时新功能的开发效率提升了约40%。特别是在微服务架构中良好的DI实践是保持代码整洁度的关键保障。