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.
下载地址:http://cuwkuhaihong.javaeye.com/blog/599584
由于是thin 1.0版,可能带有很多bug。
欢迎给出建议。
[该贴被cuwkuhaihong于2010-02-21 22:27修改过]