Spring注入依赖

引用spring的官方文档中的一段描述：

在Spring2.0之前的版本中，@Repository注解可以标记在任何的类上，用来表明该类是用来执行与数据库相关的操作（即dao对象），并支持自动处理数据库操作产生的异常

在Spring2.5版本中，引入了更多的Spring类注解：@Component,@Service,@Controller。@Component是一个通用的Spring容器管理的单例bean组件。而@Repository, @Service, @Controller就是针对不同的使用场景所采取的特定功能化的注解组件。

因此，当你的一个类被@Component所注解，那么就意味着同样可以用@Repository, @Service, @Controller来替代它，同时这些注解会具备有更多的功能，而且功能各异。

最后，如果你不知道要在项目的业务层采用@Service还是@Component注解。那么，@Service是一个更好的选择。

就如上文所说的，@Repository早已被支持了在你的持久层作为一个标记可以去自动处理数据库操作产生的异常（译者注：因为原生的java操作数据库所产生的异常只定义了几种，但是产生数据库异常的原因却有很多种，这样对于数据库操作的报错排查造成了一定的影响；而Spring拓展了原生的持久层异常，针对不同的产生原因有了更多的异常进行描述。所以，在注解了@Repository的类上如果数据库操作中抛出了异常，就能对其进行处理，转而抛出的是翻译后的spring专属数据库异常，方便我们对异常进行排查处理）。

注解	含义
@Component	最普通的组件，可以被注入到spring容器进行管理
@Repository	作用于持久层
@Service	作用于业务逻辑层
@Controller	作用于表现层（spring-mvc的注解）

@Service用于标注业务层组件 
@Repository用于标注数据访问组件，即DAO组件 
@Controller用于标注控制层组件，如Struts中的Action 
@Component泛指组件，当组件不要好归类时，可以使用这个注解进行标注 

其他网上资料

这几个注解几乎可以说是一样的：因为被这些注解修饰的类就会被Spring扫描到并注入到Spring的bean容器中。

这里，有两个注解是不能被其他注解所互换的：

@Controller 注解的bean会被spring-mvc框架所使用。
@Repository 会被作为持久层操作（数据库）的bean来使用
如果想使用自定义的组件注解，那么只要在你定义的新注解中加上@Component即可：

@Component 
@Scope("prototype")
public @interface ScheduleJob {...}

• 1
• 2
• 3

这样，所有被@ScheduleJob注解的类就都可以注入到spring容器来进行管理。我们所需要做的，就是写一些新的代码来处理这个自定义注解（译者注：可以用反射的方法），进而执行我们想要执行的工作。

@Component就是跟<bean>一样，可以托管到Spring容器进行管理。

@Service, @Controller , @Repository = {@Component + 一些特定的功能}。这个就意味着这些注解在部分功能上是一样的。

当然，下面三个注解被用于为我们的应用进行分层：

@Controller注解类进行前端请求的处理，转发，重定向。包括调用Service层的方法
@Service注解类处理业务逻辑
@Repository注解类作为DAO对象（数据访问对象，Data Access Objects），这些类可以直接对数据库进行操作
有这些分层操作的话，代码之间就实现了松耦合，代码之间的调用也清晰明朗，便于项目的管理；假想一下，如果只用@Controller注解，那么所有的请求转发，业务处理，数据库操作代码都糅合在一个地方，那这样的代码该有多难拓展和维护。

总结

@Component, @Service, @Controller, @Repository是spring注解，注解后可以被spring框架所扫描并注入到spring容器来进行管理
@Component是通用注解，其他三个注解是这个注解的拓展，并且具有了特定的功能
@Repository注解在持久层中，具有将数据库操作抛出的原生异常翻译转化为spring的持久层异常的功能。
@Controller层是spring-mvc的注解，具有将请求进行转发，重定向的功能。
@Service层是业务逻辑层注解，这个注解只是标注该类处于业务逻辑层。
用这些注解对应用进行分层之后，就能将请求处理，义务逻辑处理，数据库操作处理分离出来，为代码解耦，也方便了以后项目的维护和开发。

 

 

@Service、@Repository注解是放到service或者dao类的实现类还是接口类中

应该很多刚开始接触Spring和springMVC的小白，都会像我当时学习的时候一样，心理都会有这么一个问题，@Service、@Repository注解是放到service或者dao类的实现类还是接口类上面？会提出这个问题，一说明你是一个会思考的人，而说明你对接口的概念以及对Spring的IOC思想不是很了解。因为之前是网上碎片式的学习Spring，和直接跟着学长做项目来的实战经验，所以对很多概念性的东西或者说是底层性的东西不了解，这使得我知其然不知其所以然，也就没能更进一步提升了。所以最近开始系统性的看书，补充底层性的知识。闲话就不扯了，下面直奔主题吧。

1、首先说@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容器处理，控制权颠倒过来了，这就是控制反转的由来！

注：在控制反转与解耦过程中使用了设计模式中的工厂模式。

 工厂模式

 

工厂模式是指当应用程序中甲组件需要乙组件协助时，并不是在甲组件中直接实例化乙组件对象，而是通过乙组件的工厂获取，即该工厂可以生成某一类型组件的实例对象。在这种模式下，甲组件无需与乙组件以硬编码的方式耦合在一起，而只需与乙组件的工厂耦合

那么这样的话，通过依赖注入就可以完全不用关心对象的生命周期，什么时候被创建，什么时候销毁，只需直接使用即可，对象的生命周期由提供依赖注入的框架来管理，从而，让使用框架者，可以将重心完全放到业务逻辑处理的开发上。

 

2、spring之aop

1） 在业务系统里除了要实现业务功能之外，还要实现如权限拦截、性能监控、事务管理等非业务功能。
通常的作法是非业务的代码穿插在业务代码中，从而导致了业务组件与非业务组件的耦合。

2） aop面向切面编程，就是将这些分散在各个业务逻辑代码中的非业务代码，通过横向切割的方式抽取到一个独立的模块中，从而实现业务组件与非业务组件的解耦。

 

   可能这里有人还看不懂为什么通过第三方实现两个类的依赖关系，就可以减少代码的耦合度。实现两个类的依赖关系，有三种普通注入方式，分为构造函数的注入、属性注入、接口注入。

 

1 2 3 4 5 6 7 8

public class MovieFinder {       ... }

 

 

1 构造函数注入（Contructor Injection）

 

MovieLister就只依赖于我们定义的MovieFinder接口，而不依赖于MovieFinder的实现了。

1 2 3 4 5 6 7 8

public class MovieLister {     private MovieFinder finder;     public MovieLister(MovieFinder finder) {         this.finder = finder;     }     ... }

 

2 setter注入

类似的，我们可以增加一个setter函数来传入创建好的MovieFinder对象，这样同样可以避免在MovieFinder中hard init这个对象。

1 2 3 4 5 6

public class MovieLister {     s...     public void setFinder(MovieFinder finder) {         this.finder = finder;     } }

 

3 接口注入

接口注入使用接口来提供setter方法，其实现方式如下。
首先要创建一个注入使用的接口。

1 2 3

public interface InjectFinder {     void injectFinder(MovieFinder finder); }

之后，我们让MovieLister实现这个接口。

1 2 3 4 5 6 7

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装配顺序

1. 如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常。
2. 如果指定了name，则从上下文中查找名称（id匹配的bean进行装配，找不到则抛出异常。
3. 如果指定了type，则从上下文中找到类型匹配的唯一bean进行装配，找不到或者找到多个，都会抛出异常。
4. 如果既没有指定name，又没有指定type，则自动按照byName方式进行装配，如果没有匹配，则回退为一个原始类型（UserDao）进行匹配，如果匹配则自动装配。

 

当指定了@service的name值时， 在@Resource中要么不指示，如果指示的话，则要与之相对应。

当没有指定@service的name值是，在@Resource中随意。但是前提是，实现该接口的只有这一个类。

所以，建议是最好在@service和@Resoure中同时指定名称，并且做到一一对应。

如果采用@Autowired来注解，则同样无需指定name属性，若是实现该接口有多个类，则需要通过@Qualifier来做区分

     例：UserService、UserService2是实现IuserService的两个实现类

 

类中@Service的注解分别是

@Service("userService1")
public class UserService  implements IuserService {}

@Service("userService2")
public class UserService2 implements IuserService {}

 

那么在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属性一旦指
     定，就只会按照名称进行装配。