@Service

把DAO实现类注入到service实现类中，把service的接口(注意不要是service的实现类)注入到action中，注 

入时不要new 这个注入的类，因为spring会自动注入，如果手动再new的话会出现错误，然后属性加上 

@Autowired后不需要getter()和setter()方法，Spring也会自动注入。至于更具体的内容，等对注入的方式更 

加熟练后会做个完整的例子上来。 

 

 

 

首先说@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的实现了。

public class MovieLister {
private MovieFinder finder;

public MovieLister(MovieFinder finder) {
this.finder = finder;
}
...
}
2 setter注入
类似的，我们可以增加一个setter函数来传入创建好的MovieFinder对象，这样同样可以避免在MovieFinder中hard init这个对象。

1

public class MovieLister {
s...
public void setFinder(MovieFinder finder) {
this.finder = finder;
}
}
3 接口注入
接口注入使用接口来提供setter方法，其实现方式如下。
首先要创建一个注入使用的接口。

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

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

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

如果同时指定了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的注解分别是

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

 

 

 

 

 

为什么spring注入接口正确而注入接口的实现

 

原因所在：出现如果直接注入实现类会出现没有对应的bean，因为我们通过实现类来继承的接口，然而，必须使用jdk提供的动态代理放法，而不使用接口直接对实现类进行注入，则为cglib的注入，而不能既继承接口又使用实现类来注入的方式，这样两种代理类都是没有办法使用的。
解决方案：1.直接通过jdk去生成动态代理类，（原理要求必须实现接口）
2.通过cglib去实现接口，直接使用代理类，而不能实现接口。

 

， 报错原因： 直接注入实现类是不符合spring自己的设计规范的；
2， spring依赖注入设计思想就是利用java的多态特性，减少耦合，实现在配置文件中通过配置，实现不用更改java硬编码，达到功能切换的目的， 所以注入的只能是接口，然后配置文件中切换其实现类；
3，注解出现后，多是在java文件中用注解注入，方便省事，而且一般来说，spring带了一种设计思想，但实际上在配置文件中真正需要切换的并不多，所以为了方便，又使用了注解这种硬编码；
4， 没有什么设计是万能的，根据实现情况来决定，一接口对应一个实现类的，直接用注解吧，真到了需要多个实现的时候，注解可以取注入的别名来指定实现类，也可以像以前一样配置在XML中， 并不冲突

 

Spring动态注入的时候，如果一个类实现了一个接口，则需要利用到动态代理。

 

为了保持行为的一致性，代理类和委托类通常会实现相同的接口，所以在访问者看来两者没有丝毫的区别。通过代理类这中间一层，能有效控制对委托类对象的直接访问，也可以很好地隐藏和保护委托类对象，同时也为实施不同控制策略预留了空间，从而在设计上获得了更大的灵活性。Java动态代理机制以巧妙的方式近乎完美地实践了代理模式的设计理念。

因为JDK生成的最终真正的代理类，它继承自Proxy并实现了我们定义的接口，在实现接口方法的内部，通过反射调用了实现类的invoke方法。

 

为什么在CategoryController类中 @Auto明明注解在CategoryService 这个接口上 而注入的却是CategoryServiceImpl这个实现类
因为： (自动装配实现了CategoryService接口的的实例，只有CategoryServiceImpl实现了CategoryService接口，所以就会注入CategoryServiceImpl)

这种自动装配 @Autowired 还是@Resource在装配或者注入的时候都是先是实例化后再进行的 第一步都是先实例化

这里他要实例化一个接口是不可能的 所以要找到他的实现类 实例化他的实现类

 

 

源码分析，好好看看

https://blog.csdn.net/mack415858775/article/details/47721909
---------------------
作者：半壁江山009
来源：CSDN
原文：https://blog.csdn.net/qq_31963719/article/details/79458002
版权声明：本文为博主原创文章，转载请附上博文链接！

 

 

什么要把DAO作为接口 再用impl类来实现？