## 数据源 ##
#Tomcat封装的DBCP；
>> 基本知识；
tomcat在默认情况下已经集成了DBCP；
>> JNDI；
|-- 基本概念；
在tomcat启动的时候会根据用户的要求创建好
数据源，并根据名字将数据源绑定；它内部维护一个
Map集合，Key是一个由路径和名字构成的字符串，Value是
绑定的数据源对象；
<-??->什么是数据源；
|-- 优势；
提高获取连接的效率；
>> 基本开发步骤；
|-- 将数据库需要的驱动jar包放到lib目录下；
|-- 将登录需要的用户名和密码的XML配置文件放到META-INF目录下；
|-- 位置；
> doc --> JNDI --> Confige context...>
|-- 启动tomcat；
|-- 特别注意；
> 对于数据源的测试不要放到main方法当中测试；
## 元数据 ##
# 基本概念；
数据库，表，列等定义的信息；
简单来说就是对于Java来说，用于描述数据库的信息；
# 基本操作；
>> 基本方法接口 --- Connection
Connection.getMetaData()获取关于数据库的整体综合信息。
DataBaseMetaData 元数据对象
getURL()：返回一个String类对象，代表数据库的URL。
getUserName()：返回连接当前数据库管理系统的用户名。
getDatabaseProductName()：返回数据库的产品名称。（告诉habuneite方言是什么）
getDatabaseProductVersion()：返回数据库的版本号。
getDriverName()：返回驱动驱动程序的名称。
getDriverVersion()：返回驱动程序的版本号。
isReadOnly()：返回一个boolean值，指示数据库是否只允许读操作。
>> 具体Demo --- 参见MetaDateTest.java
# 实际应用；
因为可以通过获取元数据方式，获取到数据库中对应的列名；
由此可以和domain中UserBean对应的属性相对应；
由此可以简化DAO层中的CRUD操作；
## 自定义框架 ##
# ORM 对象关系映射；
>> Object； JavaBean对象；
>> Relation：关系型数据库；
>> Mapping；映射（存储应对关系）；
## DBUtils ##
# 基本使用；
>> 导包；
>> 定义DAO接口及实现类；
>> 直接获取QuerRunner对象便可以直接使用；
## 实际开发中的事物控制 ##
# 案例 --- 转账；
>> 基本步骤；
|-- DAO层中建立转账方法；
|-- DAO实现类中实现具体的转账方法；
|-- 具体分析；
> 源账户数据减少；
> 目标账户数据增加；
> 更新 update；
> 问题 --- 如何获取连接；
|-- QueryRunner支持无参构造；
|-- update支持重载方法中，在执行中放入链接；
> 两个update是否需要同一个链接；
> 提交事务；
|-- 如果出现异常需要进行回滚；
|-- 测试事务是否保持；
|-- 修改Client类；// 这是一个测试类，测试main方法在当中；
|-- 问题 --- DAO层中出现了业务逻辑代码；
|-- 建立一个Service类；
> 改写DAO层；
|-- 根据账户名查询得到一个账户；
|-- 根据账户名更新账户的金额；
|-- 在Service实现类中完成业务逻辑代码；
|-- 根据账户名得到账户对象；
|-- 调用DAO中方法；
|-- 根据目标对象名，得到一个目标账户；
|-- 调用DAO中方法；
|-- 更新余额；
|-- 调用对象中的方法，源账户减少，目标账户增加；
|-- 问题：链接不确定；--- 无法确保查询和更新使用的链接是同一个；
|-- 解决方案：
> 在DAO的实现类中建立一个链接；
> 通过构造参数接收一个链接；
|-- 将数据封装到表中；
> 问题 ： 如何开启事务；
|-- 该怎么开怎么开；
> 处理异常；
> 提交事务；
|-- 将setAutoCommit(true); 放到finally当中
<-??-> 这是啥？
|-- 进行测试，看事务状态是否能够保持住；
|-- 临时问题：
在回滚操作时，捕获的异常应该是Exception；
|-- 最终问题：
|-- Connection作为数据库连接应该出现在DAO中，
如果connection不存在，开启事务的代码应该不执行；
所以开启事务的代码不能放在业务层；
|-- 结论：开启事务的逻辑代码不应该放在业务层；
|-- 重新建立一个工程；
|-- 修改Service实现类；
|-- 将提交事务相关的方法都删除；
|-- 问题：事务应该放在哪一层？
|-- 解决方案；
> 参见新知识点；ThreadLocal
> 推论：
因为两次调用find方法和update方法
都在main开启的主线程当中，
所以可以考虑将它们全部封入一个
ThreadLocal线程当中，然后再将
Connection放入，好像可以解决问题...
<-??-> 我还是不知道事务应该放在哪一层；
> 去掉DAO实现类当中的con;
> 分离事务控制代码，专门用一个类来进行事务的处理；
|-- 传说中的"方面代码"；专注于处理某个方面的代码；
|-- 建立一个获取Connection的方法；
|-- 比较重要的部分，如果没有链接后面的方法都无法工作；
|-- 详细分析；
> 问题 --- 已经有连接池了，为何还需要自己获取链接？
|-- 为了保证获取到的链接的一致性；
> 引入ThreadLocal ；//用于放入Connection，并保证使用的是唯一的Connection
> 从线程局部变量中取出一个connection；
> 从连接池中取出一个链接；
> 将线程池中的链接放入线程局部变量；
|-- 建立一个开启事务的方法；
|-- 获取链接；
|-- 开启事务；
|-- 建立一个提交事务的方法；
|-- 获取链接；
|-- 提交事务；
|-- 建立一个回滚的方法；
|-- 获取链接；
|-- 回滚；
|-- 更新Service类；
>> 在第一行调用事务类的开启事务功能；
|-- 对DAO的实现类进行修改；
>> 修改对应的获取事务和链接的部分；
|-- 问题 --- 虽然进行了独立封装，但控制事务的代码依然放在业务层当中；
|-- 分析解决方案；
|-- 新建一个工程；
|-- 最终版本；
>> 分析；
|-- 新建一个BeanFactory类；
|-- 提供一个方法，返回一个AccountService对象；
|-- AOP 新知识点；(面向切面/方面编程)
> 基本概念；
将事物的某个方面的功能代码抽取出来，
进行集中实现，当系统需要用到该功能的时候，
重新将方面代码加入到系统当中；
忽略了原有继承体系的纵向结构，可以在需要的时候
横向插入关键代码；
> 实现原理；
如何完成将代码实现横向织入；
|-- 动态代理；
> 适用场景；
|-- 事务控制；
|-- 日志控制；
|-- 权限集中管理；
|-- 积分功能；
|-- 实现动态代理；
|-- Proxy.newProxyInstance(loader,interface,h){
}
|-- loader --- 需要代理的类加载器；
|-- interface --- 类所实现的接口；
|-- h
> 代理类自己的实现方法，实质上是一个
匿名内部类；
|-- 进行判断，如果方法名为需要代理的方法；
|-- 需要保证原有方法能够执行；
|-- 横向加入事务开启的方法；
|-- 进行事务的常规处理；
|-- 改写Client类；
|-- 在创建对象时不再使用new，而是使用BeanFactory的方法；
## ThreadLocal ##
# 基本概念；
内部维护一个Map集合，Key是当前线程对象，Value是一个Object对象；
由于一个线程中的值只能有当前线程能够获取；
# 基本操作方式；
>> set(Object value);
|-- 解释；
之所以只需要传入Value就可以使用，
是因为key默认的是当前线程对象，所以只需要传入
对应的value就可以设置当前线程对象的值；
>> remove();
>> get();
# 使用测试；
>> 建立一个main的测试类；
|-- 因为main默认开启了一个主线程；
>> 建立一个ThreadLocal对象；
|-- 简单测试；
> 自己放入一个值，可以自己进行获取；
>> 建立一个子线程；
|-- 通过构造方法，从父类接收一个ThreadLocal对象；
|-- 测试是否无法让其他对象访问该线程；
|-- 通过子线程调用get方法去获取main线程当中存入的值，看是否能够成功输出；