Thin，基于key-value的持久层框架

 

如今主流JEE系统的开发框架中，通常显示层使用MVC框架，中间业务逻辑层使用spring，持久层采用hibernate/JPA.这种组成几乎是毫无争议的典型架构体系，但若我们将这三个组成部分完全从我们脑海中清楚，以空杯的心态来看JEE系统的开发，我们就很容易地发现我走弯路了。IE浏览器把form表单中的所有元素以key-value方式传到后台，逻辑处理会把这些元素做相应的修改，然后存到数据库中，主流数据库是以二维表存储方式，二维表的每一条记录其实就是多个key-value。既然数据的起始端和结束端都是key-value，那么为什么我要在中间加入那么多Javabean呢（我这里并没有说不要JavaBean之类的话），如果JavaBean少一些系统开发是不是应该更快一些，维护更方便一些呢？再看看这个典型架构体系，数据通常是这样交互：formàkey-valueàformBeanàentityBeanàDB,第一箭头是IE完成，第二个是MVC框架完成，第三个就是spring处理业务逻辑时完成，第四个是hibernate/JPA完成。开发人员会经常发现formbean和entityBean很多属性是相同，存储时要做对拷，很明显有悖于复用。而产生entityBean元凶是hibernate/JPA,它以习惯性的面向对象的思想，以对象持久化封装了一组原子数据（key-value）的存储。其实持久化了东西就是很多属性的集合，即key-value的集合。entityBean是一个类，具有名称，要单纯比一组key-value更加形象。要是给这组key-value也起个名这点优势也没了；再说跨数据库，在现实开发中真正跨数据库的不太多，如果都采用JDBC+标准SQL也同样可以跨数据库；因使用它增加的学习成本，开发成本，维护成本已经覆盖了它的形象优势。

    我是想提出一种基于key-value的持久方式，没有学习曲线，大大提高开发效率，降低维护成本。这就是我开发的基于key-value持久方式的Thin，之所以起这个名字主要是这个持久框架很纤薄。

以下是thin与hibernate差异对比。

 

 

 

Thin 的设计思想来源经验，不少公司都有给出查询SQL返回一个List<String,Map<String,Object>>的方法，用于执行查询,既然有查询为什么不写出增删改的方法呢，于是Thin就诞生了，核心思想是定义了BeanTable的对象来虚拟化数据库中的表，通过操作BeanTable来操作数据库。这种直接操作数据库方式视乎背离OO的思想，其实也没有，表也是一个对象，hibernate的Entity，约束了生产力。

Thin简单到你只需要看几测试类就可以灵活运用，无配置文件，也没有用到任何自定义注解，用稍加修改就可以成为自己东西。

推荐看三个类TestBeanTable，BeanTable，DBAccesser