构造注入和@Resources注入选择

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

一、背景

项目中使用@RequiredArgsConstructor注解生成构造方法

1.1构造注入代码示例

@Slf4j
@Service
@RequiredArgsConstructor
public class UserService extends ServiceImpl<UserDao, User> {
    private final CompanyService companyService;
    private final RoleService roleService;
    private final SmsService smsService;
    private final CacheService cacheService;
}

1.2 @Resource注入代码示例

@Slf4j
@Service
public class UserService extends ServiceImpl<UserDao, User> {
    @Resource
    private final CompanyService companyService;
    @Resource
    private final RoleService roleService;
    @Resource
    private final SmsService smsService;
    @Resource
    private final CacheService cacheService;
}

二、出现的问题

循环依赖，众所周知spring解决set注入循环依赖问题，@Resource也一样，那么为什么舍近求远使用构造器注入呢？

spring官方也是推荐使用构造器注入

The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that

required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state.

构造器注入能够保证注入的组件不可变，并且确保需要的依赖不为空。此外，构造器注入的依赖总是能保证完全初始化的状态。

问题来了，上面代码里并没有在类构造初始化形成相互依赖，也没有初始化先后顺序，都是属于类构造成员变量后置处理，对成员变量的使用也是在Spring启动完成之后。

三、个人的解决

特别的问题，特别的解决方法，不应该默认全局处理。当然如果未来规划建设要拆分服务时，那么使用构造器注入代码的改动相对较少，基于聚合器模式的聚合服务，但使用@Resource注入也只是代码移动.

服务拆分难点应该也不再这里，那么你会如何选择呢？

以上是 构造注入和@Resources注入选择 的全部内容， 来源链接： utcz.com/z/512636.html

回到顶部