Home
img of docs

探讨 Spring 框架中字段依赖注入(Field Injection)的问题及其不推荐使用的原因。

chou403

/ Spring

/ c:

/ u:

/ 7 min read


为什么Spring不建议使用基于字段的依赖注入

Spring 不建议使用基于字段的依赖注入(Field Injection),主要是因为以下几个原因:

1. 无法进行依赖注入的验证

在使用基于字段的依赖注入时,依赖注入发生在对象实例化之后。Spring 容器在创建对象时无法验证这些字段是否已经成功注入,这可能会导致在运行时出现 NullPointerException

2. 不易进行单元测试

使用基于字段的依赖注入使得单元测试变得困难。要对带有字段注入的类进行单元测试,需要使用反射来设置私有字段,这不仅繁琐,而且破坏了封装性。相比之下,基于构造函数或 Setter 方法的依赖注入更容易进行单元测试,因为可以在测试时显式地提供依赖。

3. 不可变性

使用构造函数注入时,依赖项在对象创建时被注入,因此可以确保依赖项是不可变的(final),这有助于设计出更加稳定和线程安全的类。字段注入不支持这一点,因为字段必须是可变的。

4. 缺乏明确的依赖

构造函数和 Setter 方法明确地表明了一个类的依赖项,使代码更具可读性和可维护性。字段注入隐藏了依赖关系,增加了代码理解的难度。

5. 潜在的循环依赖问题

使用构造函数注入时,Spring 可以更早地检测到循环依赖,并且通过调整 bean 的创建顺序来解决这些问题。字段注入可能会在更晚的时间发现这些问题,从而导致更难调试和解决。

6. 违反了控制反转(IoC)的原则

控制反转的一个核心原则是依赖项应由外部容器管理并注入,而不是在类内部隐式地设置。字段注入在一定程度上隐藏了依赖项的注入过程,违背了这一原则。

示例对比

构造函数注入
   @Component
public class MyService {
    private final MyRepository myRepository;

    @Autowired
    public MyService(MyRepository myRepository) {
        this.myRepository = myRepository;
    }

    // 使用 myRepository
}
字段注入
   @Component
public class MyService {
    @Autowired
    private MyRepository myRepository;

    // 使用 myRepository
}

依赖注入结论

尽管基于字段的依赖注入在某些情况下可能看起来更简洁,但它在测试性,可维护性,代码清晰度和可靠性方面存在显著缺点。因此,Spring 社区和文档通常推荐使用构造函数注入,或者在需要时使用 Setter 方法注入,以确保代码的质量和可维护性。

Seata 有几种模式 重要

Seata(Simple Extensible Autonomous Transaction Architecture)是一个开源的分布式事务解决方案,致力于解决分布式系统中数据一致性的问题。Seata 提供了多种模式来管理分布式事务,主要包括:

  1. AT 模式(Automatic Transaction Mode):
    • 适用场景: 适用于支持 ACID(原子性,一致性,隔离性,持久性)事务的关系型数据库。
    • 原理: 通过代理 JDBC 数据源的方式,自动生成和管理全局事务。Seata 在执行数据库操作前后进行自动补偿。
    • 特点: 开发者无需修改现有代码,只需简单配置即可使用,适合对性能要求不太高的场景。
  2. TCC 模式(Try-Confirm-Cancel Mode):
    • 适用场景: 适用于对事务性能和精细化控制有高要求的场景。
    • 原理: 将业务逻辑分为三个阶段: Try 阶段执行业务预操作,Confirm 阶段提交事务,Cancel 阶段回滚事务。由开发者实现这些阶段的具体逻辑。
    • 特点: 需要开发者编写更多的代码,灵活性高,适用于复杂的业务场景。
  3. SAGA 模式(Long-Running Transaction Mode):
    • 适用场景: 适用于长时间运行的事务。
    • 原理: 将业务流程分解为一系列有序的子事务,每个子事务都有对应的补偿操作。在全局事务出错时,按逆序执行补偿操作。
    • 特点: 适合需要长时间处理的业务流程,如订单处理,供应链管理等。
  4. XA 模式(Distributed Transaction XA Mode):
    • 适用场景: 适用于支持 XA 协议的数据库。
    • 原理: 基于两阶段提交(2PC)协议实现的分布式事务管理器,协调多个数据库资源的提交和回滚。
    • 特点: 实现了标准的分布式事务协议,适用于传统的企业应用系统。

各模式特点总结

  • AT 模式: 使用方便,适用于简单的关系型数据库事务,但性能相对较低。
  • TCC 模式: 灵活性高,适用于对性能和事务控制要求高的复杂业务场景,但开发成本较高。
  • SAGA 模式: 适用于长时间运行的事务,支持复杂的业务流程。
  • XA 模式: 基于标准的两阶段提交协议,适用于需要严格分布式事务控制的企业应用。

这些模式为开发者提供了灵活的选择,能够根据不同的业务需求和技术环境选择合适的分布式事务解决方案。