81,094
社区成员
发帖
与我相关
我的任务
分享我对hibernate的反思和批判，以及thin的推出！
如今主流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，之所以起这个名字主要是这个持久框架很纤薄。
详情看：http://cuwkuhaihong.javaeye.com/blog/599584
我是想提出一种基于key-value的持久方式，没有学习曲线，大大提高开发效率，降低维护成本。这就是我开发的基于key-value持久方式的Thin，之所以起这个名字主要是这个持久框架很纤薄。
详情看：http://cuwkuhaihong.javaeye.com/blog/599584
...全文
请发表友善的回复…
发表回复
cuwkuhaihongting 2010-02-25
- 打赏
- 举报
谢谢你的回复，从经验来看，你多于我，但是我觉得你有点激动了。其实从你的话语中我能看出来，你是支持我的观点，只不过你没有仔细看我写东西，更没有仔细看我写代码，你说我第一句话就说错了，但是你就没有看到我第二句就开始孕育对第一句驳斥了吗。系统分层我是绝对赞同的，这和我开发thin没有任何冲突，thin设计原则也是分层，为了不让SQL导出跑。其实hibernate所实现的就跨数据库的增删改查，但是从我开始从事软件开发一来最简单的SQL：
像：
select aa,bb,cc from tableName where aa='xxx';
insert into tableName values('xxx','xx');
update.....
delete......
不用做任何修改，在常用数据库上都可以直接运行的（不要拿文件型的数据库来反驳，这个东西没有用过）。如果对此你异议的话，请举一例。
既然这些最基础的东西格式是相同，我就封装成了thin，从此不用再写这些简单的SQL，对于复杂的SQL任何框架都无法统一，hibernate不也提供了写原始SQL的方了嘛，thin也有。
thin是减少编写SQL与处理Connection的工具；
thin是以Map格式，即（key-value），作为标准数据，操作数据库的方式。
thin也同样像hibernate那样部分屏蔽了底层数据库的操作，以便分层，复杂数据库操作留有接口。
至于是否分层，完全取决于你的业务需求。责任在人，而不再工具。
对于事务，我什么时候说过事务必须要在一个会话单元完成，不要无故给我增加罪状嘛。thin可以很方便获取connection，想做什么都可以。另外我不是已经附上源代码了嘛，个别不适宜的地方改改即可，代码很简单，谁都可以写，只不过是我写出来，其他没有写，或者写了没拿出来说而已。java的优点之一
是开源，如果只知道用别人的东西，而不关系源代码的化，那和做微软的那套没什么差别。
回复“lrbyantai”：
我没有极限编程的意思，游离在业务逻辑中的bean是必不可少，实际开发中直接将想要保持的bean映射成Map，根本没有必要逐个想你所说的麻烦，你也没有看我的thin，也没有理解。同样谢谢你的关注！
BearKin 2010-02-25
- 打赏
- 举报
建议LZ先了解为何我们需要把FORMBEAN转换成实体BEAN再通过HIBERNATE存储到库中去 其中有几个必须进行的过程 这些过程为什么让我们需要这些JAVABEAN
当初JSP+SERVLET+JAVABEAN + JDBC的时候 我非常非常讨厌将前台的KEY-VALUE封装到JAVABEAN的这一过程 于是 STRUTS出现了 我很谨慎的检查其中有没有什么缺失的必要环节 结论是 没有
然后我又发觉我很讨厌将数据从JAVABEAN换成SQL这个该死的步骤 或者将查询出来的结果再封装到JAVABEAN的这一步骤 于是HIBERNATE出现了 我又很谨慎的检查 这其中有没有什么确实的必要环节 结论是 大致没有
这个过程唯一没变的只有一个:我知道我需要什么
LZ你知道你需要什么么?
当初JSP+SERVLET+JAVABEAN + JDBC的时候 我非常非常讨厌将前台的KEY-VALUE封装到JAVABEAN的这一过程 于是 STRUTS出现了 我很谨慎的检查其中有没有什么缺失的必要环节 结论是 没有
然后我又发觉我很讨厌将数据从JAVABEAN换成SQL这个该死的步骤 或者将查询出来的结果再封装到JAVABEAN的这一步骤 于是HIBERNATE出现了 我又很谨慎的检查 这其中有没有什么确实的必要环节 结论是 大致没有
这个过程唯一没变的只有一个:我知道我需要什么
LZ你知道你需要什么么?
BearKin 2010-02-25
- 打赏
- 举报
共同学习共同交流 我只不过是个编码1年多的小青年而已BearKin 2010-02-25
- 打赏
- 举报
我是不了解THIN 而且我暂时也没有欲望去了解他 但是你也不了解STRUTS或者HIBERNATE 我跟你说这些事情的原因是 我用什么东西 都是有这个过程的 进化？ 而从你对当前什么所谓的SSH的评价中 我感觉你还不足够了解他 或者说 你一开始用的时候就不知道为什么去用这个什么SSH
不是没有缺点 不过当你说JAVABEAN过多的时候你有没有想过什么原因导致过多？ 或者说过多的JAVABEAN你是怎么看待的？ 是当一堆一堆的JAVABEAN还是一堆一堆的与数据库表关联的实体呢？ 是工具是累赘呢？ 有没有尝试减少他们呢？ 然后会发生什么？
我上次回帖的时候没有办法跟你解释一些事情 因为不是解释完你就能接受的 我现在告诉你你说的几个毛病的解决办法 仅以你LS举的为例
首先 不是必须得一个Entitybean和一个业务上用的JAVABEAN 我通常会将前台一些显示的属性也写到
Entitybean中 不过他们是瞬态的 不参与持久化 然后我们公司自己开发了一套框架 一个JAVABEAN在不同的地方可以扮演不同的角色 仅仅通过一个JAVABEAN里的两个方法 类似转换器的操作
封装的过程是必须的 但是有些时候很没必要 更没必要为他新建个JAVABEAN 这是不是解决办法？
我用SSH不是为了形式主义 我是真的需要他去完成东西 希望LZ你能去体会他的好 而不是专挑某些因为什么畸形的设计思想啊 或者模式啊 而产生的恶心的事情来说 严格来说 我也认为什么编码规范是个P 但是 规范是个P的前提是 不知道为什么要规范
cuwkuhaihongting 2010-02-25
- 打赏
- 举报
这种问题永远不要拿出来问，这只能说明你不理解thin。
不知道自己想要什么，有怎么会出来thin呢，按你的思路，我解释往下说：我使用了一段时间的hibernate/JPA之后，我发现从分层的角度出发，时常我们不得不定义出两个bean，一个是hibernate所操作的Entitybean，其目的是存储；一个是业务逻辑中javabean其目的是方便操作，如界面显示，这两类是相似的。比如：
class user{
string id;
string name;
string groupid,
string groupName,//前台，或其他程序是需要的
}
class UserEntity{
string id;
string name;
string groupid;
}
这样就显得重复了，UserEntity所有的信息，user里全有。为什么还要这个呢，于是thin就出来，在开发的时候只需要把user转成map就可以做增删改查了。thin会自动帮你过滤掉不需的属性。之所以不需要是数据库中没有它的存储字段。
thin还有其他的优势。
chen09 2010-02-24
- 打赏
- 举报
没有比此更贴切的了。
LZ第一句话就错了，什么“持久层采用Hibernate/JPA.这种组成几乎是毫无争议的典型架构体系”？
还毫无争议呢。事实上Hibernate已经或正在被抛弃，原因就是楼上几位说到的，要考虑速度效率。取而代之的东西有很多，但不是说不要持久层。
我不知道LZ是不是没有事物的感念，还是LZ以为事务全是以一个会话为单位的？
“在现实开发中真正跨数据库的不太多，如果都采用JDBC+标准SQL也同样可以跨数据库；”
这话一听，就知道LZ做的开发太少。跨数据库不多，但是换用数据库的事儿经常发生。
JDBC当然都用，我是没有见过不用jdbc的java项目，LZ做过？
但是标准SQL，LZ知道什么是标准SQL？只有IBM的DB才用标准SQL（SQL是IBM发明的）！oracle的sql早就走远了，更何况mysql，postgre等免费的。
LZ如果做过售前，就应该知道，给客户做演示时写的prototype，要连各种数据库，mvc也用各种package，structs1,structs2等等，做出各种pattern的性能价格评价。没有那4层，换数据库，换mvc，将有多麻烦？
我告诉你我做个的一个售前有多少种pattern:
mvc: structs1, structs2(structs2太慢，一早被淘汰)
v: jsp , freemarker
db: oralce,mysql
orm: Hibernate, ibatis
appserver: weblogic, glassfish
我们的team一个用做了32的war，分别做普通测试，临界测试，过强度测试。
如果没有4层，难道要做32套程序？
蛋黄车 2010-02-24
- 打赏
- 举报
个人感觉spring与业务逻辑没有关系，spring的功能就是把DB连接、DAO层、Service层、action层等等实现松藕合，便于类以及层与层之间的维护！
另外，hibernate中生成的Bean并不是冗余！可能对于一个小的项目来说它生成这么多的Bean是多余的，但是，如果是一个大型的项目，要重复使用到Bean进行操作。如果你不用Bean的话，你要挨个给每个字段进行赋值并挨个的进行DML操作吗？如果是这样的话，代码量不见得比使用Bean少！哪一个效率更高那就说不定了！另外，进行复杂的逻辑判断也比较繁琐！LZ有点极限编程的意思，有点过头
cuwkuhaihongting 2010-02-23
- 打赏
- 举报
不要咬文嚼字，我用formbean不只是说structs1中特有“formbean”，而是泛指所有接受前台表单的bean；在strust2中formbean是可以没有任何继承的纯粹JavaBean；在wicket，jsf等框架中就不再有formbean的说法了，但是同样以不同的方式接受前台表单数据。用formbean显得形象一些。
cuwkuhaihongting 2010-02-23
- 打赏
- 举报
“中间业务逻辑层使用spring”就是说中间业务逻辑的服务程序一般由spring托管。
以面向对象的理念对数据库，这个观点已经不新了，开始的时候觉得很方便，慢慢地你就会发现有很多代码是重复的，如前台接受表单的bean和后台hibernate要往数据库里持久的bean。如果不用泛型的话，还要写很多讨厌的，类似的DAO，还好这个DAO可以用工具生成。但是这些不都是多余出来的代码吗？如果这些都没有了，转而被短短的几个类取代，不是更加清爽，痛快。
jafapple 2010-02-23
- 打赏
- 举报
按你的说法，创新何来？ 要欢迎新思想，新看法！以前人上天飞，那是在做梦，会被笑，现在呢？？
axman 2010-02-23
- 打赏
- 举报
无知者无畏。
数据结构和关系数据库的发展比面向对象的思想要早很多，把同一事物的不同属性组织在一起进行表示和存储，这是数据结构和关系数据库的目的。连关系数据库的“关系”指的是什么都不明白，也敢妄言“持久化”。
我本人也不看好Hibernate这类东西，仍然还是太重了。但这并不说明我们可以把有一组逻辑关系数据用KV来表示，尽管很多领域KV引擎确实简单和高效，但和关系数据库比它只占不到10%的应用，和这个主题无关。
数据是反映事物的特性和事物之间关系的表示。同样一个person数据，如果是表示我axman,那么以kv存储必须有一个id前缀，比如 axman.xxx= yyy;否则多个person不可能存储，是的，数据存储和表示解决了。
数据是被用来运算的，检索，比较和统计,分类这些处理，KV引擎能解决？
现在社会中如果你发现一个别人“没有发现”的东西，99.99999999999%的情况不是因为你聪明，而是因为大家都知道那不可行。
因为太多的东西早已被比你聪明的人发现掉了。
数据结构和关系数据库的发展比面向对象的思想要早很多，把同一事物的不同属性组织在一起进行表示和存储，这是数据结构和关系数据库的目的。连关系数据库的“关系”指的是什么都不明白，也敢妄言“持久化”。
我本人也不看好Hibernate这类东西，仍然还是太重了。但这并不说明我们可以把有一组逻辑关系数据用KV来表示，尽管很多领域KV引擎确实简单和高效，但和关系数据库比它只占不到10%的应用，和这个主题无关。
数据是反映事物的特性和事物之间关系的表示。同样一个person数据，如果是表示我axman,那么以kv存储必须有一个id前缀，比如 axman.xxx= yyy;否则多个person不可能存储，是的，数据存储和表示解决了。
数据是被用来运算的，检索，比较和统计,分类这些处理，KV引擎能解决？
现在社会中如果你发现一个别人“没有发现”的东西，99.99999999999%的情况不是因为你聪明，而是因为大家都知道那不可行。
因为太多的东西早已被比你聪明的人发现掉了。
小霍夫 2010-02-23
- 打赏
- 举报
想法是好。可一个东西要为大家接受。认可。就不是这么容易的事了。
ghchen 2010-02-23
- 打赏
- 举报
不懂楼主的想法 key-value 大大提高开发效率 是在哪一个方面?
GiveUp147 2010-02-23
- 打赏
- 举报
小的愚见“
你所谓的key-value大致就是actionFrom中的属性
1.actionForm是structs提供的视图组件，主要职责是将数据从控制器发到视图 或者 从视图发到控制器使用边界止步于控制器，不能出现在业务层
2 实体类仅是数据的载体可以跨不同的逻辑层实现数据搬运
3 当页面数据来自于一张表时，actionform于实体类的代码绝大数相同，将实体类放到actionForm中属性
”
你所谓的key-value大致就是actionFrom中的属性
1.actionForm是structs提供的视图组件，主要职责是将数据从控制器发到视图 或者 从视图发到控制器使用边界止步于控制器，不能出现在业务层
2 实体类仅是数据的载体可以跨不同的逻辑层实现数据搬运
3 当页面数据来自于一张表时，actionform于实体类的代码绝大数相同，将实体类放到actionForm中属性
”
水中影子 2010-02-23
- 打赏
- 举报
感觉对的，就拿出来给大家验证。
楼主敢于尝鲜，值得鼓励
楼主敢于尝鲜，值得鼓励
蛋黄车 2010-02-23
- 打赏
- 举报
我有点不能理解LZ所说的："中间业务逻辑层使用spring"这句话的意思。
对于hibernate，比起jdbc直连的方式要慢。效率低这点我同意LZ的观点。
但是Hibernate节省了我们开发的时间，维护也更方便。同时它是以面向对象的理念对数据库进行操作，那这种新的理念是不是也应该被我们接受呢！
一个新生事物的发展是需要被实践检验的，只有它符合了我们的要求，我们才会去用它，并不断根据需求完善它。
对于hibernate，比起jdbc直连的方式要慢。效率低这点我同意LZ的观点。
但是Hibernate节省了我们开发的时间，维护也更方便。同时它是以面向对象的理念对数据库进行操作，那这种新的理念是不是也应该被我们接受呢！
一个新生事物的发展是需要被实践检验的，只有它符合了我们的要求，我们才会去用它，并不断根据需求完善它。
cuwkuhaihongting 2010-02-23
- 打赏
- 举报
减少很多hibernate/jpa的配置，不用再写讨厌的EntityBean，以及因他们而产生代码。提高程序运行速度。
usherlight 2010-02-23
- 打赏
- 举报
原来的是这样：form-->key-value-->formBean-->entityBean-->DB
你改成了这样：form-->key-value-->formBean-->key-value-->DB？
你改成了这样：form-->key-value-->formBean-->key-value-->DB？
cuwkuhaihongting 2010-02-23
- 打赏
- 举报
对，就这么简单。
formBean是现在的一些主流MVC框架，在极端一些甚至可以变成：form-->key-value1-->key-value2-->DB。是情况而定。
cuwkuhaihongting 2010-02-23
- 打赏
- 举报
我不知道你从哪里得出我没有搞清楚“关系”数据库结论。但是持久化就是数据存储，不要想的那么复杂。
