钢炮级 持久层 —— 上篇
Title：核心处理基类
平时接到很多规模不大的小型Web项目，很多部门提出要求说需要XXX和YYY等功能，他们之间既不能保持统一操作规范或习惯，也不能统一业务和数据，在这种的情况下，悲剧的重复，带来了悲剧的工作量。
所以，我研究出一套应对我所遇到的不同需求的相同的解决方案（恩，这个词汇受到了VS的影响，以前是解决思路），为了解决编码过程中可能遇到的问题，我定了几个整体目标：
1. 系统应具有足够的访问性能，并尽量保持最少的资源消耗。
2. 持久层的重复编写是不能接受的，应达到只需 Ctrl + V 或者包引用即可解决，且无修改。
3. 该持久层内部实现，应较低的耦合，具备高兼容性、高扩展性。
4. 内部实现应尽量简单可读，计算效率低、且计算复杂同样不能接受！
具体在编码阶段，为了控制访问方式、避免Sql泛滥，我也设置几个目标：
1. 与数据库无关
2. 与表无关，实现具体表与相应的操作相分离
3. 与业务逻辑无关
要满足以上要求，不会太困难，相信坛子里也很多，好吧，废话不错说，上代码，首先介绍 DBConnection.java
然后测试select A,B,C,D,E,F from TableName where 1=1 and A=1 and B=2 and C<3
有了这些基本的处理方法，就能满足比较简单的增删改查和简单的多表查询的操作。
这个类实现以下几个目标：
1. 要查询的表在调用时指定，所以跟具体的表实现了分离；
2. 在调用该类执行操作时，需要指定操作类型（createSql方法的第一个参数），由此具体的操作类型我们可以不再关心了。
3. 逻辑比较简单：构造SQL——>执行Execute（解析结果集）——>关闭对象
4. createSql方法规范了调用方式，不会再看到泛滥的SQL，SQL被固定在了持久层，当然类型CONDITION的操作除外。
但是也有一些问题，如下：
1. 为了支持多表查询，还是妥协的暴露的一个操作类型CDONDITION，createSql方法目前还不能强大到执行复杂度太高的SQL。
2. 调用的方法显得有些复杂，做过很多思考，尽可能让createSql方法的参数简单，很遗憾，智商有限啊
3. 不能支持分页查询SQL构造，这个需求将在下一篇介绍，毕竟只是个雏形啊，哪能一蹴而就
小总结了一下，还有一些小优点：
1. 调试。你所有的SQL只会在同一个地方执行（executeSql方法），你只需要打一个断点，Ok，错误们，找到你们更easy了。
2. 这里返回的是List和Map，不是实体类对象，你可以随便造出任何实体类对象，来跟List里面的数据耦合。当然，这些实体类要实现自动与List装配，必须有一些规范，后面我也会做介绍。
总结，以上对付的，只是基于简单的数据操作，我在使用之后发现我的持久层就孤零零的几个类，代码结构简洁了许多。之后我做了一些扩展，增加分页查询的支持是必须的，对多表查询的支持我也会尽量做到（我考虑过，由于操作比较复杂，还不如直接写SQL，性价比不高```）。有任何问题和建议，希望各位看官大大的提出来，我会继续努力实现尽可能的操作简单化。
~~~平时看别人的博客没怎么在意，今天写这些居然花了一下午，En，多多锻炼````
