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

10-02-21 cuwkuhaihong

如今主流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修改过]

2
banq
2010-02-22 09:43
很有自己见解的框架。

原来我批判Hibernate/JPA,是从面向对象纯粹性来批判的,领域对象应该自己负责持久化,而不必借助外力xxx.save等命令操作;而且ORM框架实际上没有简化对象和关系数据库的阻抗,相反暴露增加了复杂性。

楼主是从key-value角度,很有创意,和目前的key/value存储NoSQL思想比较靠近。

Key-value存储是一个新趋势,视频网站豆瓣也公开了他们的开源keyvalue数据存储系统BeansDB:http://code.google.com/p/beansdb/

cuwkuhaihong
2010-02-22 10:05
banq的认可,确实让我很欣慰。

[该贴被cuwkuhaihong于2010-02-22 10:06修改过]

fireflyc
2010-02-22 11:24
好吧。
我们姑且不论key-value和关系型数据库的是非关系。

一般来说key-value数据库都需要一个比较大的内存空间来管理数据,如果采用java来设计意味着这块内存空间只能在JVM允许的范围之内,而且你根本不可以对这些内存按照自己的原则进行分配。
在看这个系统,是个单机版本的,所以应用key-value数据库都是在同一个JVM中的,这可用的内存就更少了。
java的种种限制无法实现一个高效的key-value数据库,因为根本没有办法对内存进行可定制的管理。

banq
2010-02-22 11:45
2010年02月22日 11:24 "fireflyc"的内容
采用java来设计意味着这块内存空间只能在JVM允许的范围之内,而且你根本不可以对这些内存按照自己的原则进行分配。


key-value是一个天生分布式系统,可以使用多个JVM实现,不能以单机概念对待java,Java天生就是跨网络的,跨JVM的。

tonyshen
2010-05-03 21:54
任何一个框架都不可能做到适合所有的应用场合。
有得必有失,世间万物皆如此。

很支持楼主的精神,中国太缺少自己的开源框架了。

cuwkuhaihong
2010-05-19 00:11
谢谢各位的鼓励!
在空闲时间终于完成了thin2.0

*******************************************************
thin是一个基于key-value的持久层框架,若你觉的我狂妄也可以说是工具。
thin以Map作为与数据库的交互的标准接口,thin的使用非常简单,
只需要将thin作为java project导入eclipse,
浏览test目录下测试程序即可。
*******************************************************

thin 2.0在上一个版本的基础上做了很多修改。修改内容如下:
1.重新设计了数据源管理方式,支持同时维护多个数据源。
2.添加bean与key-value的转换功能,并提供了三种转换策略
第一种是把bean中的feild名称全部大写作为key-value的key;
第二种是把bean中的feild名称中的大写字母前插入一个‘_’,然后再全部大写,如userName--->USER_NAME;
第三种是把bean中的feild加上annotation, 如jpa,另外此种方式有个默认处理方式,在feild上没有annotation时,
自动采用第一种方式处理;三种方式用户可以任意选用,用户还可以自己定义。非常简单。只要系统定好转换规则,
keyvalueConverter就可以把bean和key-value相互转换。
3.给beantable添加了iterator的功能,当查询数据量大,不易放在内存,可以采用该方式处理。
4.添加QueryBeanTable用于自定义的,复杂的SQL。但是只提供了查询功能。同时CustomBeanTable被删去。

欢迎下载测试(我没找到中国的开源项目发布网站):下载地址(http://sourceforge.net/projects/thinery/)



[该贴被cuwkuhaihong于2010-05-19 00:14修改过]

[该贴被cuwkuhaihong于2010-05-19 00:16修改过]

zm
2010-05-28 00:27
哈哈,初看标题我就大概猜中内容了,楼主是80后或是90后吧,精神不错得赞一个

说历史吧,远古时代,甚至Structs还无人知晓的时候,很多项目就是这样干的,参数少就直接写,多的话放Map里,甚至为了统一接口全部用Map,很是壮观。
但是,不久还是都改成了实际类做参数,而不是Map,Map有他的灵活性,但也会牺牲其他,比如“可读性”。看到参数的一个Map,除了知道其结构,还知道什么吗?有值无值几个值或是代表着什么意思?这个非常难表达清楚。

Map做接口参数最终被淘汰是有一定道理的,框架实现回归历史会难以被接受的,最终会落伍的,学习尚可。

不管如何,精神值得鼓励。

zm
2010-05-28 00:31
换个例子说说

常见的Get/Set方法吧,为什么要这么做呢?
学校做练习或写代码是很多不是直接把变量变成公有然后就干了吗,也很方便啊

这其中道理或许很多相似点

icycrystal4
2010-05-28 09:48
2010年05月28日 00:27 "zm"的内容
Map做接口参数最终被淘汰是有一定道理的,框架实现回归历史会难以被接受的,最终会落伍的,学习尚可。 ...


个人感觉MAP这种方式用来进行项目开发可能"最终会落伍", 但如果作为一种高度的抽象形成一个框架, 通过配置/注解的方式让项目来应用, 这即保证了可扩展性, 又能保证可理解性--可以在业务逻辑层将MAP中的数据按照配置注射到领域对象中

cuwkuhaihong
2010-05-29 00:20
2010年05月28日 00:27 "zm"的内容
但是,不久还是都改成了实际类做参数,而不是Map,Map有他的灵活性,但也会牺牲其他,比如“可读性”。看到参数的一个Map,除了知道其结构,还知道什么吗?有值无值几个值或是代表着什么意思?这个非常难表达清楚。 ...



你误解了thin,错不在你,而是我在开篇的文字,在前后台的交互和业务逻辑上说的太多。其实thin是优势是在数据库存储方面,是持久层的东西,而不是参与业务逻辑的佼佼者。在处理业务逻辑时,我还是主张采用JavaBean,在领域中做面向对象设计,在需要持久时再转成key-value,之后,javabean中的不可分离的属性,就可以离散开了,一个具有20个属性的javabean对象,要修改其中一个属性,在传统hibernate\JPA中,是要把这个对象20个属性全取出来,改其中一个再重新写入数据的,但是如果采用thin只需要2个key-value即可,一个对应主键做过滤条件,一个是被修改的值,即可完成。省去了不必要的数据库读取。

thin可以充分使用这种属性解耦的特性,处理一表对多个对象,多个表对一个对象,以及表的部分字段对对象的部分属性的存储过程,提高逻辑层与数据库交互的便利性和高效性。

不是很好嘛。

猜你喜欢