第1章 案例：使用 spring 的xml 的实现账户的CRUD
1.1 需求和技术要求
1.1.1 需求
实现账户的 CRUD 操作
1.1.2 技术要求
使用 spring 的 IoC 实现对象的管理
使用dBUtils 作为持久层解决方案
使用 c3p0 数据源
1.2 环境搭建
目录结构为：
1.2.1 拷贝相关坐标导入pom.xml
1.2.2 创建数据库和编写实体类
1.2.3 编写持久层代码
账户持久层接口
账户持久层接口实现类
查询所有：
runner.query("select * from account",new BeanHandler
BeanHandler:将结果集中封装到一个指定的javaBean中,
BeanHandler(Class
BeanLIstHandler返回一个Account类型的列表，返回多个数据时使用，再返回所有时，需要将BeanHandler改为BeanListHandler
1.2.4 编写业务层代码
业务层接口：
业务层接口实现类：(调用持久层接口)
1.2.5 创建并编写配置文件
1.4 测试案例
1.4.1 测试类代码
1.4.2 分析测试了中的问题
通过上面的测试类，我们可以看出，每个测试方法都重新获取了一次 spring 的核心容器，造成了不必要的重复代码，增加了我们开发的工作量。这种情况，在开发中应该避免发生。
我们把容器的获取定义到类中去。例如：
public class AccountServiceTest {
private ApplicationContext ac = new ClassPathXmlApplicationContext("bean.xml");
private IAccountService as = ac.getBean("accountService",IAccountService.class);
}
这种方式虽然能解决问题，但是扔需要我们自己写代码来获取容器。
能不能测试时直接就编写测试方法，而不需要手动编码来获取容器呢？
请在今天的最后一章节找答案。
第2章 基于注解的 IOC 配置
2.1明确：写在最前
学习基于注解的 IoC 配置，大家脑海里首先得有一个认知，即注解配置和 xml 配置要实现的功能都是一样的，都是要降低程序间的耦合。只是配置的形式不一样。
关于实际的开发中到底使用xml还是注解，每家公司有着不同的使用习惯。所以这两种配置方式我们都需要掌握。我们采用上一章节的案例，把 spring 的 xml 配置内容改为使用注解逐步实现。
2.2环境搭建
2.2.1 第一步：导入依赖坐标。
注意：在基于注解的配置中，我们还要多导入一个 aop 的 jar 包。如下图：
2.2.2 第二步：使用@Component 注解配置管理的资源
在需要配置的类中以及需要注入的数据上加入相关坐标：
2.2.3 第三步：创建 spring 的 xml 配置文件并开启对注解的支持
注意：基于注解整合时，导入约束时需要多导入一个 context 名称空间下的约束。
测试时，改为用读取注解的函数去读取spring容器
2.3常用注解
2.3.1 用于创建对象的
相当于：
2.3.1.1 @Component
作用：把资源让 spring 来管理。相当于在 xml 中配置一个 bean。
属性：value：指定 bean 的 id。如果不指定 value 属性，默认 bean 的 id 是当前类的类名。首字母小写。
比如说在bean里配置：
就相当于加@Component注解
2.3.1.2 @Controller @Service @Repository
他们三个注解都是针对一个的衍生注解，他们的作用及属性都是一模一样的。
他们只不过是提供了更加明确的语义化，应用于不同层
@Controller：一般用于表现层的注解。
@Service：一般用于业务层的注解。
@Repository：一般用于持久层的注解。
细节：如果注解中有且只有一个属性要赋值时，且名称是 value，value 在赋值是可以不写。
2.3.2 用于注入数据的
相当于：
2.3.2.1 @Autowired
作用：
自动按照类型注入。当使用注解注入属性时，set 方法可以省略。它只能注入其他 bean 类型。当有多个类型匹配时，使用要注入的对象变量名称作为 bean 的 id，在 spring 容器查找，找到了也可以注入成功。找不到就报错。
如图所示，注入数据时，先去找类型，比如给accountDao注入数据，他就先去spring 容器中寻找IAccountDao类型，找到之后如果只有一个就注入，如果有多个需要在根据id名称注入需要用@Qualifier注解标明id，如果没写明要注入的id名称那么报错。
2.3.2.2 @Qualifier
作用：
在自动按照类型注入的基础之上，再按照 Bean 的 id 注入。它在给字段注入时不能独立使用，必须和@Autowire 一起使用；但是给方法参数注入时，可以独立使用。
属性：value：指定 bean 的 id。
2.3.2.3 @Resource 某些意义上属于@Autowire和@Qualifier的作用
作用：
直接按照 Bean 的 id 注入。它也只能注入其他 bean 类型。
属性：name：指定 bean 的 id。
2.3.2.4 @Value
作用：
注入基本数据类型和 String 类型数据的
属性：value：用于指定值
2.3.3 用于改变作用范围的：
相当于：
2.3.3.1 @Scope
作用：指定 bean 的作用范围。
属性：
value：指定范围的值。
取值：singleton prototype request session globalsession
2.3.4 和生命周期相关的：(了解)
相当于：
2.3.4.1 @PostConstruct
作用：用于指定初始化方法。
2.3.4.2 @PreDestroy
作用：用于指定销毁方法。
2.3.5 关于 Spring 注解和 XML 的选择问题
注解的优势：
配置简单，维护方便（我们找到类，就相当于找到了对应的配置）。
XML 的优势：
修改时，不用改源码。不涉及重新编译和部署。
Spring 管理 Bean 方式的比较：
2.4spring 管理对象细节
基于注解的 spring IoC 配置中，bean 对象的特点和基于 XML 配置是一模一样的。
2.5spring 的纯注解配置
写到此处，基于注解的 IoC 配置已经完成，但是大家都发现了一个问题：我们依然离不开 spring 的 xml 配置文件，那么能不能不写这个 bean.xml，所有配置都用注解来实现呢？
2.5.1 待改造的问题
2.5.2 新注解说明
2.5.2.1 @Configuration
作用：用于指定当前类是一个 spring 配置类，当创建容器时会从该类上加载注解。获取容器时需要使用AnnotationApplicationContext(有@Configuration 注解的类.class)。
属性：value:用于指定配置类的字节码
2.5.2.2 @ComponentScan
2.5.2.3 @Bean
作用：该注解只能写在方法上，表明使用此方法创建一个对象，并且放入 spring 容器。
属性：name：给当前@Bean 注解方法创建的对象指定一个名称(即 bean 的 id）。
示例代码：
* 创建一个数据源，并存入 spring 容器中
注意:
我们已经把数据源和 runner 从配置文件中移除了，此时可以删除 bean.xml 了。
但是由于没有了配置文件，创建数据源的配置又都写死在类中了。如何把它们配置出来呢？
请看下一个注解。
2.5.2.4 @PropertySource
作用：用于加载.properties 文件中的配置。例如我们配置数据源时，可以把连接数据库的信息写到properties 配置文件中，就可以使用此注解指定 properties 配置文件的位置。
属性：
value[]：用于指定 properties 文件位置。如果是在类路径下，需要写上 classpath:
实例代码：链接数据库的配置
2.5.2.5 @Import
作用：用于导入其他配置类，在引入其他配置类时，可以不用再写@Configuration 注解。当然，写上也没问题。
属性：value[]：用于指定其他配置类的字节码。
示例代码：
2.5.2.6 通过注解获取容器：
ApplicationContext ac =new AnnotationConfigApplicationContext(SpringConfiguration.class);
小结：
当我们通过注解把相关类配置好，注入数据的时候，还有几个问题无法解决，离不开xml的配置：
第一就是我们根据注解创建对象的时候，需要告知spring框架，在读取配置文件，创建容器时，在什么包下去扫描注解，依据注解创建对象
AnnotationApplicationContext(有@Configuration 注解的类.class)。
@ComponentScan用于指定 spring 在初始化容器时要扫描的包。作用和在 spring 的 xml 配置文件中的：是一样的。
第二关于数据源和链接数据库的配置也需要通过注解来实现，通过@Bean使用此方法创建一个链接数库信息的对象和一个runner对象，并且放入 spring 容器。
第三个是创建数据源的配置如何配置出来需要@PropertySource用于加载.properties 文件中的配置。例如我们配置数据源时，可以把连接数据库的信息写到properties 配置文件中，就可以使用此注解指定 properties 配置文件的位置。
最后写一个配置类Springconfiguration它的作用和bean.xml是一样的,然后写上相关注解
@Configuration指定当前类是一个配置类
@ComponentScan作用：用于通过注解指定spring在创建容器时要扫描的包
@Import作用：用于导入其他的配置类
@PropertySource作用：用于指定properties文件的位置
这就可以删除bean.xml配置文件了
第3章 Spring 整合 Junit
3.1测试类中的问题和解决思路
3.1.1 问题
在测试类中，每个测试方法都有以下两行代码：
ApplicationContext ac = new ClassPathXmlApplicationContext("bean.xml");
IAccountService as = ac.getBean("accountService",IAccountService.class);
这两行代码的作用是获取容器，如果不写的话，直接会提示空指针异常。所以又不能轻易删掉。
3.1.2 解决思路分析
针对上述问题，我们需要的是程序能自动帮我们创建容器。一旦程序能自动为我们创建 spring 容器，我们就无须手动创建了，问题也就解决了。
我们都知道，junit 单元测试的原理，但显然，junit 是无法实现的，因为它自己都无法知晓我们是否使用了 spring 框架，更不用说帮我们创建 spring 容器了。不过好在，junit 给我们暴露
了一个注解，可以让我们替换掉它的运行器。这时，我们需要依靠 spring 框架，因为它提供了一个运行器，可以读取配置文件（或注解）来创建容器。我们只需要告诉它配置文件在哪就行了。
3.2配置步骤
3.2.1 第一步：拷贝整合 junit 的必备 jar 包到 lib 目录
此处需要注意的是，导入 jar 包时，需要导入一个 spring 中 aop 的 jar 包。
3.2.2 第二步：使用@RunWith 注解替换原有运行器
3.2.3 第三步：使用@ContextConfiguration 指定 spring 配置文件的位置
3.2.4 第四步：使用@Autowired 给测试类中的变量注入数据
3.3为什么不把测试类配到 xml 中
在解释这个问题之前，先解除大家的疑虑，配到 XML 中能不能用呢？
答案是肯定的，没问题，可以使用。那么为什么不采用配置到 xml 中的方式呢？
这个原因是这样的：
第一：当我们在 xml 中配置了一个 bean，spring 加载配置文件创建容器时，就会创建对象。
第二：测试类只是我们在测试功能时使用，而在项目中它并不参与程序逻辑，也不会解决需求上的问题，所以创建完了，并没有使用。那么存在容器中就会造成资源的浪费。
所以，基于以上两点，我们不应该把测试配置到 xml 文件中。