DB数据源配置之抽象
做java三年多了，换个框架或者设计个架构就会发现，数据源每次都是问题；
好在网上解决方案很多，然而很少有说明是引用的具体包结构，或者数据源的配置思路；
不管怎么说，各种框架也提供了各种方式，然而数据源配置依然是坑。
所以好好记录一下，关于数据源配置的问题。本文主要用来回答以下四个问题：
1.为什么要配置数据源？
2.数据源配置信息都由什么构成？
3.数据源配置方式的本质是什么？
4.数据源为什么会有多种配置方式？
1.为什么要配置数据源？
菜鸟时期，总在考虑，为啥需要一个properties文件来写个数据源配置，写成xml不行么，写死在java代码中不行么？
现在想想，当时脑子有点逗，作为极端逻辑主义，电脑是必须明白每一个细节才能够工作的；
我们的程序是经常需要保存的，就好像游戏攻略中，存档一样重要，存档就是一种持久化，保证关机以后这个东西好好的保存了。
所以对于数据库的链接，是必须要配置个数据源的，这里的数据源，狭义上指的是对数据库的链接配置。
毕竟是存永久性数据的，不可能随意被他人更改，因此衍生出了很多属性，基本上必须包括：
必须有一个唯一导航地图（url）；
必须有唯一交通工具（dirver）；
必须有唯一身份证（username）；
必须有唯一验证口令（password）；
所以，本质上数据源是在配置通往数据库的路，给固定的交通工具，按照既定路线，到达地点刷卡，对口令。
这就是数据源存在的必要性了。
2.数据源配置信息都由什么构成？
数据源的配置信息，本质上只有上述的四个内容来构成，当然由于环境或应用场景的不同，数据源还有众多的衍生配置：
最大链接数量，最小链接数量，请求超时时间，连接最长保持时间，缓存大小等。
这些衍生配置并不是必须的配置，但是也是必要的配置，需要给予一定的默认值，来保证能满足于这个运行环境。
最小链接数量（停车场中保存的巴士数量）；
最大链接数量（行进路线中最多可以并排多少个车通过同一个检查站）；
请求超时时间（检查站没人等多久）；
链接最长保持时间（卸货允许的最大时间）；
缓存大小（车厢容积）；
此外还有其他的一些配置。
3.数据库配置方式的本质是什么？
目前来说，DataSource是众多数据源配置方式的标准模式，很多框架都使用统一的标准来配置数据源。
DataSource允许手动配置的内容大概如下图：
这里不用细究，实际上，只要创建了DriverManagerDataSource对象，只要将内容设置进去就可以了。
然而获取这个参数的方式是比较多的，如：
①从properties获取；②从XML获取；③从Java文件中获取；④从Catche中获取；⑤从Bean中获取等等
获取源头众多不说，获取方式也众多，如：
①用注解自动装配Bean；②用XML解析；③用IO获取等等；
之所以本文用抽象来说，因为不论何种获取方式，多数在面对一个架构或者框架的时候，
很多人都是从网上直接搜代码的，一个一个尝试，经常会忽略以下几个问题：
①该数据源的配置方式对应的框架版本
②该数据源的配置方式是否适合你的实际应用场景
③该配置方式提供者是否提供给了正确或足够的解释说明
综上，个人认为，了解一个数据源的构成，了解应用场景，了解数据源获取的本质是十分重要的。
本质上，数据源配置到跑通测试，主要分为以下五个步骤：
①定义数据源字符串（可以是xml，properties，txt，java，db，catche等多种方式不限定的）
②获取该数据源字符串（可以使用对应框架的方法和工具，可以使用原生的方法，可以自己封装）
③设置数据源并封装成DataSource对象（
org.springframework.jdbc.datasource.DriverManagerDataSource
和 javax.sql.DataSource
本质上是同一个类型，前者可设置数据源，后者作为封装返回对象
）
④将该数据源封装对象作为参数传递给某种SessionFactory的创建方法作为参数，以此创建SessionFacotry
⑤用创建的SessionFacotry去创建session，至于这个创建session时单例还是多例，自己去把控了就。
至于怎样去写这几个类，是否封装成一个类，是否使用单例，是否使用工厂模式，是否使用订阅模式等；
应该就是仁者见仁的了，自己去写一段时间，踏几次坑比啥都强。
4.数据源为什么会有多种配置方式？
数据源的配置方式多样性，看起来是每个框架在重复造轮子，还有很多框架会提供多种配置方式。
表面上看是这样，实际上不然。原因如下：
①如果数据源是唯一的，那么应该写死在代码中，因为很少有人写死在代码中，所以数据源不唯一是常用场景！
②数据本身是做持久化使用的，因此保证数据的持久化正确，保证持久化的数据不丢失，是基本需求！
③数据源本身路径是不固定的，可能是变化的，可能在已经运行的实际环境中会有备份，切换，维护等！
④数据源可能由于服务器故障需要切换到备用服务器，或者因为服务器压力要做负载均衡，数据源会变化！
⑤分布式应用中，为了更新，防止单点故障等，数据源切换也要方便，即使是在正式运行环境中！
⑥大型分布式或集群中，数据源是依靠‘心跳’来检测可用性与压力的，所以数据源是随动的，量大也不可能人工管理。
因此，数据源不写死在代码中，而是使用外部文件来写明，保证该文件可修改。
因此，数据源如果是从‘中央数据库’、‘缓存注册中心’来获取，也是一种实际需求了。
还因此，数据源的配置文件，在部署以后，知道实际部署地址，有权限的人可以直接手动更改文件内容，也可以自行提供
更改接口或者API来做。这也是实际部署后，该文件随class文件一同被web-inf文件保护起来的原因。
因此，了解数据源的获取方式，配置方式，切换方式（error发现机制，aop切换等），才能够搭建出健壮性和扩展性
更强的系统架构。
以上！✧(∗≧ꇴ≦)人(≧ꈊ≦∗)✧