夢見館

就在框架正要写完的时候，我突然想起Query类缺了一个很重要的功能——分页查询。这是实际应用中十分常见的需求，毕竟每次都查出全部记录没有必要而且影响性能，合理做法是根据页面仅查出相应的记录就好。要实现分页查询本身很简单，只要在SQL后面加上LIMIT语句即可（具体得看是什么数据库），但现在却存在一个问题。很多时候，我们会同时用到排序与分页，按照Query类目前的实现，排序是在查询之后才进行的，这意味着返回结果是先分页后排序的列表，并不符合真实场景的需要。当然，对排序后的列表执行subList是可以得到期望的结果，但此时已经把所有记录完整查出来了，试问这样得来的分页还有意义吗？

之前嫌麻烦不把排序做到查询里面，现在为了支持分页还是躲不过它，那好吧我改还不成。先看几个简单点返回列表的方法：

public List<T> getFullList() throws Exception {

    return getResultList(false, null, -1, -1);

}

public List<T> getLazyList() throws Exception {

    return getResultList(true, null, -1, -1);

}

public List<T> getSortList(LinkedHashMap<String, Boolean> rule) throws Exception {

其实，设计和实现上该说的我已经说完了，这个纵表泛型框架要问还缺点什么的，那大概就是一份“配置指南”了。用过Hibernate或者JPA泛型框架的朋友，应该对这方面的配置会有点心得了，我这里也不打算照搬那套东西出来卖弄，换点口味研究一下如何简化配置吧。先看我在测试期间的Spring配置文件是怎么写的：

首先，第12行启用了注解配置功能，扫描的包路径视个人情况而定吧，当然最好不要太懒直接写个星号完事。接着第13行启用了注解事务功能，由于事务管理器的id已为默认的transactionManager，所以不用在这里显式指定。往下3个Bean分别是数据源、事务管理器、JdbcTemplate，注意我的数据源连的仅仅是SQLite而且没有连接池，这里你应该要换成DBCP或者C3P0这些数据源，反正以前怎么配现在就怎么配。好了，框架的公共配置就只有这么多，往下就是具体的各个Dao和Service了。你可以看到第26行的userDao，它实际的类就是BaseDao，通过构造注入实体类User，但是你看不到依赖注入JdbcTemplate实例，也看不到用parent属性指定抽象类注入。因为这都没有必要，我们的BaseDao懂得自己注入JdbcTemplate实例，依靠里面的@Autowired注解。第29行的userService同样类似，它的实际类是BaseService，不过这次需要构造注入的是一个Dao实例，引用上面定义的userDao即可。

就这样，你迅速拥有了可用的userDao和userService，同理构建出其他Dao与Service都是轻而易举，但

关于Query这个泛型查询类，先看一部分代码：

public class Query<T> {

private IBaseDao<T> baseDao;

    private JdbcTemplate jdbcTemplate;

    private Class<T> clazz;

    private StringBuffer sql;

    private List<Object> params;

public Query(IBaseDao<T> baseDao, JdbcTemplate jdbcTemplate, Class<T> clazz) throws Exception {

        this.baseDao = baseDao;

        this.jdbcTemplate = jdbcTemplate;

        this.clazz = clazz;

        this.sql = new StringBuffer("SELECT pk FROM " + clazz.getSimpleName() + " t WHERE field='pk'");

        this.params = new ArrayList<Object>();

    }

    ……（以下是各种应用方法）

}

Query类有5个全局变量，前3个通过构造方法在Dao调用createQuery方法时注入，同时为

最后一个分析的是修改方法，之所以写得那么晚，是因为它会依赖到其他方法：

public void edit(T object) throws Exception {

    update(object);

}

update这个私有方法只需要把目标对象传入即可，一开始我们就把它的主键取了出来，因为后面到处都要用到。首先处理的是原生类型属性，修改一项原生类型属性值其实只要执行一条UPDATE语句就好，问题是程序无法得知哪个属性需要修改，因此只能把所有属性都修改掉了，不管它的值有没有变化。注意这次我把JdbcTemplate批量更新的结果拿回来了，因为目标对象里肯定有pk属性，所以结果数组至少也会有一个元素。第160行把这个肯定存在的首个元素取出来，如果值等于0的话，说明UPDATE语句没有更新到任何记录，出现这种情况要么是仍未保存即主键为空的对象，要么是主键被人为修改导致在数据库找不到的对象，不管是哪样这里都会抛出异常终止方法。

如果没有异常就继续往下，第161行开始处理复杂类型属性，也就是修改子对象。如果真的只是对原有子对象进行修改还好说，但万一你是用新建对象覆盖掉原有子对象的话，递归调用update方法肯定会遇到上面所说的异常。统一的解决方案是，先调用前面说过的deleteChild方法删除原有子对象，然后取出现有子对象，要是不为空就调用insert方法新增到数据库。其实只对原有子对象进行修改的话，里面的主键必然是存在的，进入insert方法就会优先用它作为主键而不会重新生成UUID，保证了前后主键不会发生变化。

前面分析保存方法的时候已经顺带说明了ReflectUtils的一些方法，后面就可以轻松不少了，下面开始讲查找方法：

public T find(String pk) throws Exception {

    return (T) select(pk, null, null).get(null);

}

看起来也许有点费解，select其实是内部一个私有方法，它返回的是一个Map，目标查找对象可通过null键获取。理论上通过主键pk其实只能找出一个对象（或者为空），那为何不直接返回这个对象而要包一层Map呢？原因是，这个Map有可能装的是多个对象，至于为什么会这样，稍后自有分晓。下面来看这个神奇的select方法：

事实上，这个方法可以同时用于查找父对象或者子对象，若查找父对象的话只需要填参数1，若查找子对象的话则只需要填参数2和3，第233行准备的变量isRoot正是代表这个区分。下一行的变量type用于确定当前要查找的实体类型，如果是查父对象那直接就等于全局变量clazz，反之从传入参数field确定该属性的类型。再下一行的变量isList判断了上面的type是否List类型，因为复杂类型的列表是当成多个子对象保存的，这种情况下就应该把type改成列表的泛型。

紧接着，根据isRoot构造出不同的SQL进行查询，如果查不到任何记录的话直接返回空的objectMap即可，反之就往objectMap放入一个初始化的对象，并作为第243行定义的当前操作对象object

增删改查的实现是整个纵表泛型框架难点所在，下面将按照我的编写顺序逐一给大家分析，首先是保存方法：

public String save(T object) throws Exception {

        return insert(object, null, null);

}

其实只是调用了内部一个名为insert的私有方法，代码比较长这里直接贴出截图：

第1个传入参数是当前要保存的对象，第70行我们先尝试获取一下它当前的主键，用的是ReflectUtils一个静态方法：

public static Object getProperty(Object object, String name) throws Exception {

    Field field = object.getClass().getDeclaredField(name);

    field.setAccessible(true);

    return field.get(object);

}

参数1是目标对象，参数2是属性名称，由于规定了实体类的属性必须私有，所以必须先把accessible设置为true，然后才能获取到里面的属性值，设置方法setProperty同理，后面不再赘述。事

表结构和实体类已经搞清楚了，但这只是框架依赖的条件而已，框架本身的设计现在才真正开始。我们先直接看产出物吧，其实就写了那么6个东西而已，甚至我自己都觉得简单过头了。

前面4个一目了然，分别是基础Dao和Service的接口与实现，往下的Query是一个泛型查询类，以后会有详细介绍，最后的ReflectUtils是一个反射工具类，里面封装了一些静态方法，比如说获取和设置对象的属性值、转换数据类型等等。正如平时写代码一样，开始总要先定义Dao的接口，那我们就看看IBaseDao里面都有些什么方法吧：

public String save(T object) throws Exception;

public void edit(T object) throws Exception;

public void remove(String pk) throws Exception;

public T find(String pk) throws Exception;

public String getFK(T object) throws Exception;

public Query<T> createQuery() throws Exception;

前面4个就是Dao必不可少的增删改查，命名和用法上应该也很大众化了，大家按照以往的习惯去用就好。以save方法为例解释一下，传入参数是你需要保存的对象，T说明这是一个泛型，也就是说类型并不固定，保存成功后返回Stri

最初萌发折腾纵表的念头是在公司去年的一个项目，因为性质有点特殊，大概需要设计500张数据表，关系结构也许不算复杂，但是字段可能非常多而且没什么规律。按照以往的做法，先用建模工具设计数据表，然后用Hibernate Tools生成实体和映射，最后再进行Dao和Service的编写。Dao和Service有现成的泛型框架所以还好说，真正麻烦的地方实际上是前期建表，那个工作量实在是太大了。当时有一位同事提议用纵表，我仔细考虑过其实是可行的，于是就有了这个所谓的纵表泛型框架。虽然，这个项目后面还是采用常规的横表来做了，但是个人觉得这个纵表泛型框架也有点意思，所以现在就从箱底翻出来修改一下，配合本文以作记录。

在设计开始前首先要理解纵表的概念，与之相对的是我们平时常用的横表，一个典型的User表也许类似这个样子：

改用纵表保存的话，这个User表将会变成如下结构：

可以看到，原来在横表里的1条记录在纵表里被拆分成4条，每条记录分别用字段名field和字段名value去保存，并且辅以一个主键字段pk来标识它原来属于哪条记录。理论上说，纵表的记录数=横表的记录数×字段数，就算id这个字段可以不用单独1行保存，那也仍然是一个足够庞大的数字了。这样的话纵表到底好处在哪里呢，最明显的莫过于结构固定，你可以用同样的CREATE语句（当然表名还是要改的）把所有数据表快速建完。其次是扩展性，增加字段在纵表里只是增加记录而已，而横表则要大动干戈把结构改掉。虽然纵表不方便理解和操作，但存在即合理，关键就看我们如何应用而已。

明白了什么是纵表之后，我来讲