乐趣区

关于linux:Spring-IoC是如何进行依赖注入的

jiezi

依赖注入（DI）

DI（Dependency Injection），Spring IoC 不是一种技术，而是一种思维，通过这种思维，可能领导咱们设计出松耦合的程序代码。而 Spring IoC 这个思维的作用体现在两个方面，一是如何将 Bean 拆卸到容器中去以及如何从容器中获取 Bean，二是如何解决 Bean 之间的依赖关系，换句话说，就是如果由 IoC 容器来治理依赖关系，当一个 Bean 须要依赖另外一个 Bean 时，IoC 容器如何实现这样的依赖关系。

解决 Spring 中 Bean 之间的依赖的实现形式，在 Spring 的概念中就被称之为 依赖注入（Dependency Injection，DI）。普遍认为的 Spring 依赖注入的实现形式有三种：构造方法注入、setter 办法注入、注解注入。但，就我而言，我认为应该划分为两种模式——基于 XML 注入和基于注解注入，而后再细分为上面的模式：

基于 XML 的注入形式是咱们最先学习和应用的形式，也是最相熟的形式，就简略的做个介绍，举个例子。

  • 通过构造方法注入
public class UserServiceImpl implements UserService {
    
    private UserDao userDao;
    
    public UserServiceImpl(UserDao userDao) {this.userDao = userDao;}
    
    /** 继承自 UserService 的办法 **/
}

首先定义一个服务层UserServiceImpl，而后在其外部减少对 dao 层的援用userDao。

接下来就是增加一个构造方法 public UserServiceImpl(UserDao userDao) 以待 Spring 通过这个办法为 userDao 注入实例。

<!-- 注册 userDao-->
<bean id="userDao" class="com.klasdq.sb.c1.di.dao.impl.UserDaoImpl"></bean>

<!-- 注册 userService 并注入 userDao-->
<bean id="userService" class="com.klasdq.sb.c1.di.service.impl.UserServiceImpl">
        <constructor-arg name="userDao" ref="userDao"></constructor-arg>
</bean>

最初在 Spring XML 配置文件中注入相应的 bean 实例。

通过构造方法的注入，必须要注入类中具备对应的构造方法，若没有对应的构造方法，会呈现报错。

  • 通过 setter 办法注入

批改 UserServiceImpl.java 为：

public class UserServiceImpl implements UserService {

    private UserDao userDao;
    
    public void setUserDao(UserDao userDao) {this.userDao = userDao;}
    
    /** 继承自 UserService 的办法 **/
}

再批改 XML 文件内容为：

<!-- 注册 userDao-->
<bean id="userDao" class="com.klasdq.sb.c1.di.dao.impl.UserDaoImpl"></bean>

<!-- 注册 userService 并注入 userDao-->
<bean id="userService" class="com.klasdq.sb.c1.di.service.impl.UserServiceImpl">
        <property name="userDao" ref="userDao"></property>
</bean>

这两种形式的区别在于，一、UserServiceImpl.java能够不必增加构造方法，然而必须存在一个无参构造方法（如 public UserServiceImpl()，示例外面没写，是因为 java 默认会提供一个无参构造方法）以供 Spring 容器注册生成 Bean（如userService）。二、XML 文件中，采纳构造方法注入时，须要应用<constructor-arg ></constructor-arg> 这对标签；而在 setter 办法注入时，应用 <property ></property> 标签。

在 XML 注入过程中，除了应用 ref="" 援用之外，还能够应用 value="" 设定具体的值，其成果和应用注解 @Value 差不多。

基于注解的依赖注入

@Autowired
  • 源码
@Target({ElementType.CONSTRUCTOR,
         ElementType.METHOD,
         ElementType.PARAMETER,
         ElementType.FIELD,
         ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Autowired {boolean required() default true;
}

@Autowired是基于注解的依赖注入的关键点，它的源码非常简单，只有一个参数request()，这个参数的作用是标识注入 Bean 是否肯定要注入，也就是说，在 Spring 容器没有找到相应 Bean 时，如果其值为true，就会报出异样；如果其值为false，就不会出现异常，但在应用过程中，如果容器始终不对 Bean 进行注入，那么有可能呈现空指针异样。

另外一点就是，源码当中的 @Target 所蕴含的参数正好就是基于注解的依赖注入的注入形式品种，@Target决定了 @Autowired 可能标注在哪些类型下面。

  • 通过构造方法注入
@Service("userService")
public class UserServiceImpl implements UserService {
    
    private UserDao userDao;
    
    @Autowired
    public UserServiceImpl(UserDao userDao) {this.userDao = userDao;}
    /** 继承自 UserService 的办法 **/
}

依据开发文档的说法，这种只有一个构造方法的状况，自 Spring4.3 当前，就不再须要增加 @Autowired 标注，也能够。然而，如果有多个构造方法时，是必须要对其中一个办法标注 @Autowired, 不然 Spring 会报出异样。

  • 通过 setter 办法注入
@Service("userService")
public class UserServiceImpl implements UserService {

    private UserDao userDao;

    @Autowired
    public void setUserDao(UserDao userDao) {this.userDao = userDao;}
    /** 继承自 UserService 的办法 **/
}
  • 通过字段注入
@Service("userService")
public class UserServiceImpl implements UserService {

    @Autowired
    private UserDao userDao;
    
    /** 继承自 UserService 的办法 **/
}
  • 通过办法入参注入

下面三种注入形式，都是比拟相熟的就不再多做论述了。重点说一下参数注入，其实办法入参注入形式感觉上是和构造方法、setter 办法注入模式差不多，相当于将构造方法、setter 办法上的注解 @Autowired 放到入参的地位。说起来可能有些形象，间接看例子：

@Component
public class UserDaoImpl implements UserDao {
    // 简略返回一个 User，模仿数据库查找过程
    @Override
    public User getUser(Long id, String name){User user = new User();
        user.setId(id);
        user.setName(name);
        user.setAccount("12345678911");
        user.setPassword("******");
        user.setOtherInfo("this is a test account");
        return user;
    }
}
//UserService 类
@Service("userService")
public class UserServiceImpl implements UserService {

    private UserDao userDao;
   
   public UserServiceImpl(@Autowired UserDao userDao，@Autowired User user) {System.out.println("UserServiceImpl:"+user);
       this.userDao = userDao;
   }
    
    @Override
    public User getUser(Long id, String name){return userDao.getUser(id,name);
    }
}
// 简略的配置类
// 作用就是为标有 @Componet（@Service 也算）注解的类 生成 Bean
// 同时 为 @Autowired 标识下的 Bean（对象）注入实例
@Configuration
@ComponentScan
public class DIConfig {
    
    // 用于 Service 类中入参 user 的注入
    @Bean
    public User getUser(){User u = new User();
        u.setName("user inject into service");
        return u;
    }
}
// 测试类
// 留神：应用 JUnit4 测试时，如果须要应用 @Autowired 注入那么必须增加
//@RunWith    标注应用 Spring 形式启动（或者 SpringBootRunner）//@ContextConfiguration  扫描配置类
@RunWith(SpringRunner.class)
@ContextConfiguration(classes = DIConfig.class)
public class DITest {

    // 如果不增加测试类上两个注解，会注入失败
    @Autowired
    private UserService userService;

    @Test
    public void testAutowired(){ System.out.println(userService.getUser(1L,"name"));
    }
}

运行测试方法之后就失去以下后果：

public UserServiceImpl(@Autowired UserDao userDao，@Autowired User user) 中的输入后果：

public void testAutowired()测试方法中的输入后果：

留神这里 public UserServiceImpl(@Autowired UserDao userDao，@Autowired User user) 的入参：

userDao是 UserServiceImpl 的字段，但 user 不是。也就是说，咱们能够在构造方法中增加任意参数，只有是咱们须要的，不肯定要求该参数是类中属性字段。

此外还有须要留神的是，这里所说的办法，不是任意的办法，而是构造方法或 setter 办法，这种 public void initService(@Autowired UserDao userDao) 自定义的办法是无奈实现注入的。

@Primary 和 @Qualifier

在下面的例子中，咱们注入应用到的 bean，都只是容器中只有一个 Bean 实例的状况。那么当容器当中呈现多个同类型的 Bean 时，如何解决呢？

批改配置类代码如下：

@Configuration
@ComponentScan
public class DIConfig {

    @Bean
    public User getUser(){User u = new User();
        u.setName("this is user");
        return u;
    }

    @Bean
    public User getUser2(){User u = new User();
        u.setName("this is user2");
        return u;
    }
}

批改测试类：

@RunWith(SpringRunner.class)
@ContextConfiguration(classes = DIConfig.class)
public class DITest {
    
    @Autowired
    private User user;

    @Test
    public void testAutowiredPriamry(){System.out.println(user);
    }
}

当不做其余解决时，后果为：

因为有两个 User Bean（getUser , getUser2，@Bean 未注明的状况下，默认办法名为 Bean Name）的存在，所以 Spring 无奈确定应用那个进行注入。

批改形式：

  • 在 @Bean 中设置 name，如 @Bean(name="user")，当名字可能匹配上private User user; 时，也能实现注入。
  • 将 private User user 改写成 getUser 或getUser2任意一个，也能实现注入。情理和下面一样，Spring 首先会依照 type 进行匹配，如果无奈匹配，再依照名字匹配，都匹配不上时，天然抛出异样。

除此之外呢，Spring 为咱们提供了两个注解来打消依赖注入时的歧义问题。

  • @Primary
@Target({ElementType.TYPE,    // 类、接口、枚举类型
         ElementType.METHOD})// 办法
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Primary {}

@Primary是一个设定雷同类型 Bean 优先级的注解，也就是说，一旦在某个类型上增加 @Priamry，当注入时，没有明确指定 Bean 时，就会注入被@Priamry 标识的 Bean。

@Configuration
@ComponentScan
public class DIConfig {

    @Primary
    @Bean
    public User getUser(){User u = new User();
        u.setName("this is user");
        return u;
    }

    @Bean
    public User getUser2(){User u = new User();
        u.setName("this is user2");
        return u;
    }
}

比方下面这样，在 getUser() 上增加相应注解，测试方法也能失常运行。

然而这种办法的问题就在于 @Priamry 能够用在很多类上，如果同一类型有多个 Bean 被标注了 @Primary，那么@Priamry 就失去了应有的成果。

  • @Qualifier

因而，Spring 又提供了 @Qualifier 这个注解，间接标注在 @Autowired 注入的 Bean 上，为其明确指定注入某个 Bean。

@Target({ElementType.FIELD, 
         ElementType.METHOD, 
         ElementType.PARAMETER, 
         ElementType.TYPE, 
         ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Qualifier {String value() default "";
}

@Qualifier能够呈现任何 @Autowired 可能呈现的中央，与之配套应用。比方上面这样：

@RunWith(SpringRunner.class)
@ContextConfiguration(classes = DIConfig.class)
public class DITest { 

    // 间接指定应用 getUser2 进行注入
    @Autowired
    @Qualifier("getUser2")
    private User user;

    @Test
    public void testAutowiredPriamry(){System.out.println(user);
    }
}

这两种注解都能够打消歧义，举荐应用 @Bean(name="xxx") 和 @Qualifier(value="xxx")组合应用的形式 `。然而如果开发环境中没有歧义的存在，天然也就不须要应用这些了。

当然，下面只是对于 @Autowired 一些罕用介绍，如果想要理解更多，能够查看 Annotation-based Container Configuration。这个参考文档当中有着更加具体、丰盛的介绍。

总结

总得来说，Spring 是如何实现 IoC 的呢？首先，Spring 提供了一个获取和治理 Bean 的 IoC 容器。而后，再提供了一套依赖注入的机制去帮忙 IoC 容器更好地治理各个 Bean 之间的依赖关系，从而更好地实现 IoC 的思维。一个 Bean 不可能齐全脱离其余 Bean 的依赖关系而独立存在，当一个 Bean 须要其余 Bean 的引入能力初始化时，就须要依赖注入这个机制。

举例来说，如果存在一个 A 类想要去调用 B 接口的办法或者说须要 B 接口的一个实例。

传统的程序流程是，应用一个 C 类实现 B 接口，而后 A 类创立一个 C 类的实例，从而调用其办法。

在 Spring 的依赖注入过程中就变成了，A 类只须要在本人的外部增加一个注入接口（狭义上的接口，不是 interface 这个接口），这个接口能够是构造方法，也能够是 setter 办法或者说其余模式；同时增加一个对 B 接口的援用（private B b;）。

当真正须要生成 A 类的实例时，Spring IoC 容器依据 A 类提供的接口，为其注入相应的 Bean，而这个 Bean 能够是 C 类（class C implements B{}），也能够 D 类（class D implements B{}）等等；具体是谁，依据 Bean 的拆卸策略和 IoC 容器中的 Bean 来确定，不再由开发人员治理。

最初，最近很多小伙伴找我要Linux 学习路线图，于是我依据本人的教训，利用业余时间熬夜肝了一个月，整顿了一份电子书。无论你是面试还是自我晋升，置信都会对你有帮忙！

收费送给大家，只求大家金指给我点个赞！

电子书 | Linux 开发学习路线图

也心愿有小伙伴能退出我，把这份电子书做得更完满！

有播种？心愿老铁们来个三连击，给更多的人看到这篇文章

举荐浏览：

  • 干货 | 程序员进阶架构师必备资源免费送
  • 神器 | 反对搜寻的资源网站
退出移动版