本文转载自:https://blog.csdn.net/qq_35923749/article/details/77159213
首先说@Service、@Repository注解的作用吧,也就是IOC的思想,IOC中文就是控制反转,但这个晦涩难懂,所以有个新词代替这个词就是依赖注入,就是,调用类对某个接口实现类的依赖调用由第三方(Spring的容器)来实现,以移除调用类对某一接口实现类的依赖,从而减少代码的耦合度。
那么通过控制反转(IOC)是怎么实现减少耦合的呢?总结网上的说法,从两个角度出发 1、控制反转① 软件系统在没有引入IoC容器之前,对象A依赖对象B,那么A对象在实例化或者运行到某一点的时候,自己必须主动创建对象B或者使用已经创建好的对象B,其中不管是创建还是使用已创建的对象B,控制权都在我们自己手上。
②如果软件系统引入了Ioc容器之后,对象A和对象B之间失去了直接联系,所以,当对象A实例化和运行时,如果需要对象B的话,IoC容器会主动创建一个对象B注入到对象A所需要的地方,。
③ 通过前面①②的对比,可以看到对象A获得依赖对象B的过程,由主动行为变成了被动行为,即把创建对象交给了IoC容器处理,控制权颠倒过来了,这就是控制反转的由来!
注:在控制反转与解耦过程中使用了设计模式中的工厂模式。
工厂模式
工厂模式是指当应用程序中甲组件需要乙组件协助时,并不是在甲组件中直接实例化乙组件对象,而是通过乙组件的工厂获取,即该工厂可以生成某一类型组件的实例对象。在这种模式下,甲组件无需与乙组件以硬编码的方式耦合在一起,而只需与乙组件的工厂耦合
那么这样的话,通过依赖注入就可以完全不用关心对象的生命周期,什么时候被创建,什么时候销毁,只需直接使用即可,对象的生命周期由提供依赖注入的框架来管理,从而,让使用框架者,可以将重心完全放到业务逻辑处理的开发上。
spring之aop
1) 在业务系统里除了要实现业务功能之外,还要实现如权限拦截、性能监控、事务管理等非业务功能。
通常的作法是非业务的代码穿插在业务代码中,从而导致了业务组件与非业务组件的耦合。
2) aop面向切面编程,就是将这些分散在各个业务逻辑代码中的非业务代码,通过横向切割的方式抽取到一个独立的模块中,从而实现业务组件与非业务组件的解耦。
实现两个类的依赖关系,有三种普通注入方式,分为构造函数的注入、属性注入、接口注入。
以MovieFinder类举例
public class MovieFinder { ... }
1 构造函数注入(Contructor Injection)
MovieLister就只依赖于我们定义的MovieFinder接口,而不依赖于MovieFinder的实现了。
public class MovieLister {
private MovieFinder finder;
public MovieLister(MovieFinder finder) {
this.finder = finder;
}
...
}
2.setter注入
类似的,我们可以增加一个setter函数来传入创建好的MovieFinder对象,这样同样可以避免在MovieFinder中hard init这个对象。
public class MovieLister {
s...
public void setFinder(MovieFinder finder) {
this.finder = finder;
}
}
3, 接口注入
接口注入使用接口来提供setter方法,其实现方式如下。首先要创建一个注入使用的接口。
public interface InjectFinder {
void injectFinder(MovieFinder finder);
}
然后,我们让MovieLister实现这个接口
class MovieLister implements InjectFinder {
...
public void injectFinder(MovieFinder finder) {
this.finder = finder;
}
...
}
以上三种注入方式,虽然实现了解耦,但多余了很多代码来实例化MovieFinder,MovieLister和MovieFinder两个类并没有完全解耦,那如果将注入方式交给第三方呢?通过bean的注解,想调用时直接通过注解注入,挥之即来用之即去,这就是IOC的创建的初衷。
2、所以通过注解注入bean,就是实例化依赖类的方式,这也是为什么要将@Service和@Repository放到实现类上面而不是接口类上面,接口只是一个规范,需要各种实现类去实现这个接口,我们要用的就是这些实用类的方法。
3、注入的方式有@Recource和@Autowired
@Resource的作用相当于@Autowired,只不过@Autowired按byType自动注入,而@Resource默认按 byName自动注入罢了。
@Resource有两个属性是比较重要的,分别是name和type,spring将@Resource注解的name属性解析为bean的名字,而type属性则解析为bean的类型。所以如果使用name属性,则使用byName的自动注入策略,而使用type属性时则使用byType自动注入策略。如果既不指定name也不指定type属性,这时将通过反射机制使用byName自动注入策略。@Resource装配顺序
- 如果同时指定了name和type,则从Spring上下文中找到唯一匹配的bean进行装配,找不到则抛出异常。
- 如果指定了name,则从上下文中查找名称(id匹配的bean进行装配,找不到则抛出异常。
- 如果指定了type,则从上下文中找到类型匹配的唯一bean进行装配,找不到或者找到多个,都会抛出异常。
- 如果既没有指定name,又没有指定type,则自动按照byName方式进行装配,如果没有匹配,则回退为一个原始类型(UserDao)进行匹配,如果匹配则自动装配。
当指定了@service的name值时, 在@Resource中要么不指示,如果指示的话,则要与之相对应。
当没有指定@service的name值是,在@Resource中随意。但是前提是,实现该接口的只有这一个类。
所以,建议是最好在@service和@Resoure中同时指定名称,并且做到一一对应。
如果采用@Autowired来注解,则同样无需指定name属性,若是实现该接口有多个类,则需要通过@Qualifier来做区分
例:UserService、UserService2是实现IuserService的两个实现类
@Service("userService1")
public class UserService implements IuserService {}
@Service("userService2")
public class UserService implements IuserService {}
类中@Service的注解分别是
那么在TestMethod中测试方法,使用接口IuserService时,使用的@Autowired来标注时,需要使用注解@Qualifier来做区分
@Autowired
@Qualifier("userService2")
private IuserService userService;
@Resource(name="loginService")
private LoginService loginService;
@Autowired(required=false)@Qualifier("loginService")
private LoginService loginService;
(1).@Autowired 与@Resource都可以用来装配bean. 都可以写在字段上,或写在setter方法上;
(2).@Autowired 默认按类型装配,默认情况下必须要求依赖对象必须存在,如果要允许null值,可以设
置它的required属性为false,如:@Autowired(required=false) .如果我们想使用名称装配可以结合 @Qualifier注解进行使用;
(3).@Resource(这个注解属于J2EE的),默认安装名称进行装配,名称可以通过name属性进行指定,如果没有指定name属性,当注解写在字段上时,默认取字段名进行安装名称查找,如果注解写在setter方法上默认取属性名进行装配。当找不到与名称匹配的bean时才按照类型进行装 配。但是需要注意的是,如果name属性一旦指定,就只会按照名称进行装配。