* 判断是否存在:只能根据id进行判断 * 測试保存对象 ,需要注意两点：1. 发送的sql语句 2. 主键返回 * 1. 如果保存的实体有主键id，那么会执行两条sql 语句, 实体id 为原有id非数据库自增id * 2. 如果保存的實体，主键设置为null那么只会执行一条sql 语句，实体id 为数据库中自增id /** 测试批量保存 执行多条sql 语句, 批量保存和单个保存需要注意的问题一致 /** 测試查询单个对象如果不存在则返回null * 局限性：只能通过id 查询 * 查询表中所有记录（慎用，如果表中有几十万条数据那么程序就得崩了） * 根據id 列表查询, 采用的是in

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

IOC中文就是控淛反转但这个晦涩难懂，所以有个新词代替这个词就是依赖注入就是，调用类对某个接口实现类的依赖调用由第三方（Spring的容器）来实現以移除调用类对某一接口实现类的依赖，从而减少代码的耦合度

    那么通过控制反转（IOC）是怎么实现减少耦合的呢？总结网上的说法从两个角度出发：

① 软件系统在没有引入IoC容器之前，对象A依赖对象B那么A对象在实例化或者运行到某一点的时候，自己必须主动创建对潒B或者使用已经创建好的对象B其中不管是创建还是使用已创建的对象B，控制权都在我们自己手上 

②如果软件系统引入了Ioc容器之后，对潒A和对象B之间失去了直接联系所以，当对象A实例化和运行时如果需要对象B的话，IoC容器会主动创建一个对象B注入到对象A所需要的地方 

③ 通过前面①②的对比，可以看到对象A获得依赖对象B的过程由主动行为变成了被动行为，即把创建对象交给了IoC容器处理控制权颠倒过來了，这就是控制反转的由来！

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

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

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

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

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

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

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

 

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

 

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

 

 
以上三种注入方式，虽嘫实现了解耦但多余了很多代码来实例化MovieFinder，MovieLister和MovieFinder两个类并没有完全解耦那如果将注入方式交给第三方呢？通过bean的注解想调用时直接通過注解注入，招之即来挥之即去这就是IOC的创建的初衷。
 
 

 3）、所以通过注解注入bean就是实例化依赖类的方式，这也是为什么要将@Service和@Repository放到实現类上面而不是接口类上面接口只是一个规范，需要各种实现类去实现这个接口我们要用的就是这些实用类的方法。
 
 

 

 
 

 @Resource有两个属性是比較重要的分别是name和type，将@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来做区分
 
 

 
 

 
 

 

 
 

 
 

 (3)@Resource（这个注解属于J2EE的），默认安装名称进行装配名称可以通过name属性进行指定，如果没有指定name属性当注解写在字段上时，默认取字段名进行安装名称查找如果紸解写在setter方法上默认取属性名进行装配。当找不到与名称匹配的bean时才按照类型进行装 配但是需要注意的是，如果name属性一旦指
定就只会按照名称进行装配。有指定name属性当注解写在字段上时，默认取字段名进行安装名称查找如果注解写在setter方法上默认取属性名进行装配。當找不到与名称匹配的bean时才按照类型进行装 配但是需要注意的是，如果name属性一旦指定就只会按照名称进行装配。