- 浏览: 418909 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (244)
- struts2 (15)
- ognl (1)
- hibernate (17)
- gwt (17)
- GROOVY (2)
- GRAILS学习 (7)
- SPRING (4)
- AJAX (2)
- JQUERY (6)
- XML (1)
- DWR (3)
- 线程 (0)
- SVN (0)
- json (1)
- anotation (0)
- 反射 (2)
- rapidframework (0)
- OA工作流 (2)
- 事务 (0)
- mysql (0)
- oracle (26)
- EXTJ (0)
- 求职 (2)
- 随笔 (22)
- 注释 (1)
- java综合 (30)
- 设计模式 (1)
- JSP SERVLET (2)
- 插件 (7)
- 应用 (3)
- HTML (5)
- flex (13)
- android (8)
- javascript (14)
- Exception (0)
- Linux (2)
- 计算机常识 (3)
- EXCEL (2)
- 正则表达式 (1)
- 开源工具 (2)
- 测试 (1)
- 生活 (7)
- 房子 (0)
- 购房大学 (4)
- UML (1)
- 服务器 (1)
- 发展 (1)
- 英语 (1)
- 项目管理 (1)
- 摘 (1)
- 网站 (1)
最新评论
-
a347911:
架构师教程:https://note.youdao.com/s ...
架构师之路--- 一个四年 JAVA 程序员的工作经历 转 -
hzxlb910:
对我帮助很大。
架构师之路--- 一个四年 JAVA 程序员的工作经历 转 -
xly_971223:
引用因此,while (!isInterrupted())也可 ...
Java 终止线程方法 -
zdglt88:
其实这个datagrid挺简单的,没有难度
Jquery easy ui 之datagrid简介 -
完善自我:
抓住重点,支持一下!
Jquery easy ui 之datagrid简介
最近论坛上关于Hibernate的帖子很多,发表一下我的看法。
过去,MySQL火爆异常,那段时间,我也盲目的跟着研究了一把MySQL。
可是,直到今天,我再也没有用到过MySQL。仔细想一下,无非两个原因:
1。用MySQL的项目,要么业主没钱可花要么是自己玩儿,可我是一个打工的,我需要养家糊口,所以这样的项目我不能做,做这样项目的公司我不能去,我承认我还是停留在钱的层次上在编程。
2。如果你作为负责人,即使项目不需要事务功能,难道你就会向业主推荐不要钱(现在要钱了)的MySQL?出了问题谁负责?
可能这个例子不太恰当,Structs也好,Hibernate也好虽然获得了一部分人的积极响应,但他们都不是标准,我不用他们一样可以好好的活着,我为什么要研究他们,为什么要将我的项目绑在他们身上,如果将来收费了,如果我需要对其进行改造,怎么办?
退一步说,公司这么多人,要求每个人都会Hibernate吗?要求每个人都会Structs吗?招来新人后,你给多长时间让他学习?
我的观点是研究Structs不如认真研究JSP,Servlet规范先,万一你遇见我这样的,你给我讲Structs我听不懂,也不想听懂,反过来我问你 Tag Lib,你又答不上来,怎么办?关键在于,我了解规范不了解Structs理直气壮,但了解Structs不了解Tag Lib或者写不出像样的Tag,谈何理直气壮?
与其研究Hibernate,我不如研究EJB规范,EJB QL,EJB设计等。
这是一个道路选择问题,搞Java,Sun的东西和Sun认可的东西才是康庄大道,才是硬道理。当然了,武侠中的高手通常是无所不知,无所不晓,但不管怎么说,既然有九阳神功,九阴真经可练为什么偏偏要练千蛛万毒手呢?
相应一下Robin的号召(怎么都是问问题的),欢迎讨论。
个人看法,有不妥之处请手下留情。
我觉得你很逗,是否学习一个知识,没有人能够帮你回答这个问题,只有你自己能够回答,如果你觉得需要学习,那么就去学习,如果你觉得不需要,那么就不要浪费时间,难道你学习不学习,还要别人帮你做决定吗?那么生活中那么多比是否学习Hibernate更重用的决定,你又要找谁来帮助你做决定呢?父母吗?做人是否应该有点自己的主见?
每个学习 Hibernate人都有他的原因和需要,或者因为工作需要,或者因为兴趣使然,或者打发无聊时间,或者人云亦云,你又是哪一种呢?我看你是自己不想学习 Hibernate,觉得对自己的工作没有什么用处,也浪费宝贵的时间,但是你看到论坛那么多人都在学习Hibernate,又特别不甘心,生怕万一不学习,又错过了真正的好东西。真矛盾阿,所以一定要别人帮助你找出来一个让自己学习或者不学习的理由。
其实我觉得你的情况已经很清楚了,你不应该学习Hibernate,因为你用不到,就这么简单。拿我来说吧,虽然很多人都说,学习Java编程,一定要研究Jive和Petstore源代码,然而当我开始研究Jive和Petstore的源代码以后,我认为他们太理论化了,不实用,也许对别人有重大用处,但是对我则是毫无帮助,于是我就不去学习了。再拿GOF的设计模式来说吧,我从来不觉得GOF的设计模式对我有什么用处,我也根本不去学习GOF设计模式,但是我觉得J2EE设计模式对我特别有帮助,所以我会花时间去学习。虽然无数的人都说学习Java编程必学GOF设计模式,但是我认为对我来说没用,我就不去学习,就是到现在我也只能说过四五中GOF设计模式而已,但我不会因为别人的观点对我产生什么动摇。
J道J道,解决问题之道,真是精辟,真理。
本人非常同意Robbin的看法,呵呵,象Robbin这样道行的人确实不多见。
从业时间久了,专注于技术方案的设计与实现,以前见过不少自称是很牛的牛人,但大都或视野狭窄,专攻某一语言某一技术,任何系统都是程咬金的三斧头,系统虽说可以工作,但结果惨不忍睹;或华而不实,纸上谈兵,抱着UML等高深理论来套业务流程,结果往往更惨……
构建完美的系统是很多同人的目标与追求,什么样系统是完美的?首先要完美的符合商业应用的需要,这是评判系统好坏的硬道理。一味追求技术先进、体系优美、灵活扩展等如果偏离了应用的基本需求,是没有什么好处的。举例来说,本人在实时交易系统方面有过些经验,评判这样系统的标准大体就象下面概括的:交易事务的ACID必须保证,足够的安全性,在此基础上把业务逻辑正确的编码出来基本上就是一个不错的系统了,如果在体系结构、灵活扩展、集群负载均衡等面面俱到,就可以说是个完美的系统了。
技术人员在方案选择上往往有很多不同的看法和分歧,我认为这里面存在一个方向的问题,就是技术人员面对各种日新月异的技术时怎样取舍,是要技术视野博大还是技术专向精深的问题。本人一直坚持的一个观点就是,尽可能的对相关的领域知识要博大,然后把兴趣集中在某一方面,在这一方面做到精深。在我看来,现在大多数的技术人员,甚至是很多具有多年开发经验的老手都是专攻某项技术,甚至某一编程语言,知识面狭窄,而在项目方案选择上往往有失偏颇。
我来谈谈我为什么学习Hibernate,希望对大家能有点启发。
在我做过的很多项目的过程中,我一直有一个悬而未决的问题在困扰我,那就是持久层的开发。持久层的开发一般来说要么用CMP,要么用JDBC+DAO。 CMP就不用说了,它对我来说是一种失败的实践,而JDBC+DAO也存在很多的困难,我很难做到把关系表记录完整的映射到持久对象的关系上来,这主要体现在多表的关系无法直接映射到对持久对象的映射上来,可能是一个表映射多个持久对象,有可能是多个表映射一个持久对象,更有可能的是表的某些字段映射到一个持久对象,但是另外一些字段映射到别的持久对象上。而且即使这些问题都处理好了,也不能直接按照对象的方式来对持久对象(PO)编程,因为存在1:N关系的持久对象的查询其实就是1+n次对数据库的SQL,我曾经有一次失败的持久层设计,结果是某个关联很多其它持久对象的PO一查询就是5n+1次 sql,速度慢的不得了,最后不得不整个修改底层设计,最后等于是完全抛弃了对象设计,完全是按照表字段进行操作。
但是这样做非常难受,因为系统的设计是从需求设计,系统设计这样自顶而下的,结果都到了详细设计阶段了,被持久层映射问题限制,不得不自底向上修改设计方案,又回到了按照过程进行编程的老路上来,非常的糟糕。
我对这个问题思考了很久,最后终于意识到这其实是一个很经典的问题:对象和关系的映射问题。实际上自从OOP编程流行以后,就存在这个难题了,所以才有人提出关系数据库进行重新设计,改用对象数据库,但实际上关系数据库并没有被淘汰,于是就只能在上层的应用层找解决方案。这时候我明白了我需要的实际上是一种ORM产品。
我最早想到的ORM就是JDO,于是我下载了两个JDO产品,准备认真的学习一下,但是研究了一段时间之后,我发现我对JDO非常的失望,原因如下:
1、 JDO没有一个好的开源免费实现,好的产品都是商业产品,并且在国内没有销售和技术支持。这就造成了JDO只有学习之用,不能把它用在实际项目中,否则的话,你把软件卖给客户的时候,还要告诉他,你还要另外去买一个国外的软件产品,并且在国内没有技术支持,出了持久层的问题,我们也解决不了,请你自己打国际长途去解决问题,你认为客户能答应吗?
2、JDO不是一个轻量级封装,它试图建立一个完整的持久层框架,但是还很不完善,造成了JDO 感觉比较笨重,很多操作方式令人觉得烦琐和古怪。这加重了程序员学习和编程的负担,而且封装的太多会造成一个严重的问题就是一旦出现报错信息,调试起来非常困难,你很难准确的定位错误究竟出在哪里,封装的越轻,问题越容易定位,越容易解决,封装的越重,问题越复杂,越找不到原因,CMP就是一个很好的例子,出了错误,调试起来非常困难和麻烦。
3、JDO的标准很不完善,存在重大缺陷。最主要的问题体现在PO不能脱离PM(相当于 Hibernate的Session)而存在,这是个非常严重的问题,会造成编程的时候进行大量VO的拷贝操作,烦琐极了;另外一个重大缺陷是静态的 POJO的Enhancer,不能运行期动态Enhance,无法进行增量编译和调试,编程和调试起来非常烦琐,每次都要手共运行一个工具对POJO进行 Enhance;此外还有一些缺陷,例如JDOQL不完善,映射关系的表达不够强大等等。
4、JDO产品的分裂。这个问题也比较严重,由于JDO1.0标准的缺陷,而JDO2.0标准还遥遥无期,而各个JDO厂商为了能够在竞争中脱颖而出,那么除了在易操作性和性能上的提高之外,想要吸引客户,就必须有自己的产品特色。那么1.0标准的缺陷正好给了他们发挥的舞台,每个厂商都会有自己独到的解决方案来解决标准的缺陷,然而这却造成了JDO 产品事实上的分裂。这种分裂严重到什么程度?我可以简单举个例子:你写好的POJO,用一种JDO的Enhancer进行Enhance过以后得到的 PO,在另一个JDO产品上跑不起来。这很像当年Unix的分裂,结果就是二进制代码级的不兼容,而只能在C源代码级兼容。现在的JDO也有这样的趋势,就像App Server的差别一样,一个在Weblogic上开发好的EJB,移植到Websphere,你一定需要重新进行配置。
我心目中的ORM最好有如下的特点:
1、开源和免费的License,我可以在需要的时候研究源代码,改写源代码,进行功能的定制。
2、轻量级封装,避免引入过多复杂的问题,调试容易,也减轻程序员的负担。
3、具有可扩展性,API开放,当本身功能不够用的时候,可以自己遍码进行扩展。
4、开发者活跃,产品有稳定的发展保障。
抛弃了JDO以后,我根据上面的原则,先后排除了TopLink,CocoBase,Castor等,最后选择了Apache OJB和Hibernate。
OJB的排除很容易做出,一是因为它的文档太简单,太少;二是因为OJB计划下一个版本全面支持JDO,它的API会有重大变动,所以现阶段学习OJB是个错误,等它的API稳定了以后再学习不迟。
Hibernate的发现是很偶然的事情,只是在别人提到JDO的产品中,附带提了提而已,但当我开始研究Hibernate之后,我发现终于找到了我梦寐以求的ORM了。
Hibernate 完全符合我上面提到的标准之外,也解决掉了JDO的所有缺陷,而且方式之优雅令人赞叹。Hibernate的文档也是非常非常有特色的地方,它不仅仅是 Hibernate的功能介绍那么简单,它实际上是一个持久层设计的最佳实践的经验总结,文档里面的例子,文档里面的总结全部都是最佳设计的结晶。我认真的把Hibernate读下来的感觉就是,不单单把Hibernate掌握住了,而且对持久层的设计的经验都长了一大块,以前可从来没有觉得持久层的设计还有那么多的学问,也由此感觉到Gavin绝对是一个大牛人。
当然选择Hibernate最最重用的原因是Hibernate是一个我能够完完全全驾驭的了的软件。Hibernate的源代码非常少,而且写的非常简洁,我总觉得挺奇怪的,这么少的源代码能够实现这么多的功能,是个奇迹。 Hibernate的源代码树分的很清楚简单,源代码很易读,我一旦碰到文档中没有讲到的问题,或者文档中提到但是我搞不清楚的地方,我就去源代码中找,所有的问题都豁然开朗,而且让我对Hibernate的运行原理和细节搞的特别清楚,好像Hibernate就像自己写的代码一样,很清楚的知道,怎么写程序可以让Hibernate运行效率最高,最省内存,程序出了错误,很清楚的知道是什么地方的问题,怎么解决。所以用Hibernate让我特别放心,我能够驾驭它,而不像那些过于复杂的软件,本身框架就复杂的很,再加上不开源,出了问题也不知道怎么回事。
如果你认真看看Hibernate文档,就应该知道Hibernate支持集群。但是在集群操作下有一些限制,例如不能使用read-write cache等。
10亿的单子确有其事。我不觉得Hibernate用在大项目中有什么奇怪的,本质上就是JDBC的一个轻量级封装而已,如果你能在大单子中用JDBC,又为什么不能用Hibernate呢?反到是大单子用CMP太危险了。
过去,MySQL火爆异常,那段时间,我也盲目的跟着研究了一把MySQL。
可是,直到今天,我再也没有用到过MySQL。仔细想一下,无非两个原因:
1。用MySQL的项目,要么业主没钱可花要么是自己玩儿,可我是一个打工的,我需要养家糊口,所以这样的项目我不能做,做这样项目的公司我不能去,我承认我还是停留在钱的层次上在编程。
2。如果你作为负责人,即使项目不需要事务功能,难道你就会向业主推荐不要钱(现在要钱了)的MySQL?出了问题谁负责?
可能这个例子不太恰当,Structs也好,Hibernate也好虽然获得了一部分人的积极响应,但他们都不是标准,我不用他们一样可以好好的活着,我为什么要研究他们,为什么要将我的项目绑在他们身上,如果将来收费了,如果我需要对其进行改造,怎么办?
退一步说,公司这么多人,要求每个人都会Hibernate吗?要求每个人都会Structs吗?招来新人后,你给多长时间让他学习?
我的观点是研究Structs不如认真研究JSP,Servlet规范先,万一你遇见我这样的,你给我讲Structs我听不懂,也不想听懂,反过来我问你 Tag Lib,你又答不上来,怎么办?关键在于,我了解规范不了解Structs理直气壮,但了解Structs不了解Tag Lib或者写不出像样的Tag,谈何理直气壮?
与其研究Hibernate,我不如研究EJB规范,EJB QL,EJB设计等。
这是一个道路选择问题,搞Java,Sun的东西和Sun认可的东西才是康庄大道,才是硬道理。当然了,武侠中的高手通常是无所不知,无所不晓,但不管怎么说,既然有九阳神功,九阴真经可练为什么偏偏要练千蛛万毒手呢?
相应一下Robin的号召(怎么都是问问题的),欢迎讨论。
个人看法,有不妥之处请手下留情。
我觉得你很逗,是否学习一个知识,没有人能够帮你回答这个问题,只有你自己能够回答,如果你觉得需要学习,那么就去学习,如果你觉得不需要,那么就不要浪费时间,难道你学习不学习,还要别人帮你做决定吗?那么生活中那么多比是否学习Hibernate更重用的决定,你又要找谁来帮助你做决定呢?父母吗?做人是否应该有点自己的主见?
每个学习 Hibernate人都有他的原因和需要,或者因为工作需要,或者因为兴趣使然,或者打发无聊时间,或者人云亦云,你又是哪一种呢?我看你是自己不想学习 Hibernate,觉得对自己的工作没有什么用处,也浪费宝贵的时间,但是你看到论坛那么多人都在学习Hibernate,又特别不甘心,生怕万一不学习,又错过了真正的好东西。真矛盾阿,所以一定要别人帮助你找出来一个让自己学习或者不学习的理由。
其实我觉得你的情况已经很清楚了,你不应该学习Hibernate,因为你用不到,就这么简单。拿我来说吧,虽然很多人都说,学习Java编程,一定要研究Jive和Petstore源代码,然而当我开始研究Jive和Petstore的源代码以后,我认为他们太理论化了,不实用,也许对别人有重大用处,但是对我则是毫无帮助,于是我就不去学习了。再拿GOF的设计模式来说吧,我从来不觉得GOF的设计模式对我有什么用处,我也根本不去学习GOF设计模式,但是我觉得J2EE设计模式对我特别有帮助,所以我会花时间去学习。虽然无数的人都说学习Java编程必学GOF设计模式,但是我认为对我来说没用,我就不去学习,就是到现在我也只能说过四五中GOF设计模式而已,但我不会因为别人的观点对我产生什么动摇。
J道J道,解决问题之道,真是精辟,真理。
本人非常同意Robbin的看法,呵呵,象Robbin这样道行的人确实不多见。
从业时间久了,专注于技术方案的设计与实现,以前见过不少自称是很牛的牛人,但大都或视野狭窄,专攻某一语言某一技术,任何系统都是程咬金的三斧头,系统虽说可以工作,但结果惨不忍睹;或华而不实,纸上谈兵,抱着UML等高深理论来套业务流程,结果往往更惨……
构建完美的系统是很多同人的目标与追求,什么样系统是完美的?首先要完美的符合商业应用的需要,这是评判系统好坏的硬道理。一味追求技术先进、体系优美、灵活扩展等如果偏离了应用的基本需求,是没有什么好处的。举例来说,本人在实时交易系统方面有过些经验,评判这样系统的标准大体就象下面概括的:交易事务的ACID必须保证,足够的安全性,在此基础上把业务逻辑正确的编码出来基本上就是一个不错的系统了,如果在体系结构、灵活扩展、集群负载均衡等面面俱到,就可以说是个完美的系统了。
技术人员在方案选择上往往有很多不同的看法和分歧,我认为这里面存在一个方向的问题,就是技术人员面对各种日新月异的技术时怎样取舍,是要技术视野博大还是技术专向精深的问题。本人一直坚持的一个观点就是,尽可能的对相关的领域知识要博大,然后把兴趣集中在某一方面,在这一方面做到精深。在我看来,现在大多数的技术人员,甚至是很多具有多年开发经验的老手都是专攻某项技术,甚至某一编程语言,知识面狭窄,而在项目方案选择上往往有失偏颇。
我来谈谈我为什么学习Hibernate,希望对大家能有点启发。
在我做过的很多项目的过程中,我一直有一个悬而未决的问题在困扰我,那就是持久层的开发。持久层的开发一般来说要么用CMP,要么用JDBC+DAO。 CMP就不用说了,它对我来说是一种失败的实践,而JDBC+DAO也存在很多的困难,我很难做到把关系表记录完整的映射到持久对象的关系上来,这主要体现在多表的关系无法直接映射到对持久对象的映射上来,可能是一个表映射多个持久对象,有可能是多个表映射一个持久对象,更有可能的是表的某些字段映射到一个持久对象,但是另外一些字段映射到别的持久对象上。而且即使这些问题都处理好了,也不能直接按照对象的方式来对持久对象(PO)编程,因为存在1:N关系的持久对象的查询其实就是1+n次对数据库的SQL,我曾经有一次失败的持久层设计,结果是某个关联很多其它持久对象的PO一查询就是5n+1次 sql,速度慢的不得了,最后不得不整个修改底层设计,最后等于是完全抛弃了对象设计,完全是按照表字段进行操作。
但是这样做非常难受,因为系统的设计是从需求设计,系统设计这样自顶而下的,结果都到了详细设计阶段了,被持久层映射问题限制,不得不自底向上修改设计方案,又回到了按照过程进行编程的老路上来,非常的糟糕。
我对这个问题思考了很久,最后终于意识到这其实是一个很经典的问题:对象和关系的映射问题。实际上自从OOP编程流行以后,就存在这个难题了,所以才有人提出关系数据库进行重新设计,改用对象数据库,但实际上关系数据库并没有被淘汰,于是就只能在上层的应用层找解决方案。这时候我明白了我需要的实际上是一种ORM产品。
我最早想到的ORM就是JDO,于是我下载了两个JDO产品,准备认真的学习一下,但是研究了一段时间之后,我发现我对JDO非常的失望,原因如下:
1、 JDO没有一个好的开源免费实现,好的产品都是商业产品,并且在国内没有销售和技术支持。这就造成了JDO只有学习之用,不能把它用在实际项目中,否则的话,你把软件卖给客户的时候,还要告诉他,你还要另外去买一个国外的软件产品,并且在国内没有技术支持,出了持久层的问题,我们也解决不了,请你自己打国际长途去解决问题,你认为客户能答应吗?
2、JDO不是一个轻量级封装,它试图建立一个完整的持久层框架,但是还很不完善,造成了JDO 感觉比较笨重,很多操作方式令人觉得烦琐和古怪。这加重了程序员学习和编程的负担,而且封装的太多会造成一个严重的问题就是一旦出现报错信息,调试起来非常困难,你很难准确的定位错误究竟出在哪里,封装的越轻,问题越容易定位,越容易解决,封装的越重,问题越复杂,越找不到原因,CMP就是一个很好的例子,出了错误,调试起来非常困难和麻烦。
3、JDO的标准很不完善,存在重大缺陷。最主要的问题体现在PO不能脱离PM(相当于 Hibernate的Session)而存在,这是个非常严重的问题,会造成编程的时候进行大量VO的拷贝操作,烦琐极了;另外一个重大缺陷是静态的 POJO的Enhancer,不能运行期动态Enhance,无法进行增量编译和调试,编程和调试起来非常烦琐,每次都要手共运行一个工具对POJO进行 Enhance;此外还有一些缺陷,例如JDOQL不完善,映射关系的表达不够强大等等。
4、JDO产品的分裂。这个问题也比较严重,由于JDO1.0标准的缺陷,而JDO2.0标准还遥遥无期,而各个JDO厂商为了能够在竞争中脱颖而出,那么除了在易操作性和性能上的提高之外,想要吸引客户,就必须有自己的产品特色。那么1.0标准的缺陷正好给了他们发挥的舞台,每个厂商都会有自己独到的解决方案来解决标准的缺陷,然而这却造成了JDO 产品事实上的分裂。这种分裂严重到什么程度?我可以简单举个例子:你写好的POJO,用一种JDO的Enhancer进行Enhance过以后得到的 PO,在另一个JDO产品上跑不起来。这很像当年Unix的分裂,结果就是二进制代码级的不兼容,而只能在C源代码级兼容。现在的JDO也有这样的趋势,就像App Server的差别一样,一个在Weblogic上开发好的EJB,移植到Websphere,你一定需要重新进行配置。
我心目中的ORM最好有如下的特点:
1、开源和免费的License,我可以在需要的时候研究源代码,改写源代码,进行功能的定制。
2、轻量级封装,避免引入过多复杂的问题,调试容易,也减轻程序员的负担。
3、具有可扩展性,API开放,当本身功能不够用的时候,可以自己遍码进行扩展。
4、开发者活跃,产品有稳定的发展保障。
抛弃了JDO以后,我根据上面的原则,先后排除了TopLink,CocoBase,Castor等,最后选择了Apache OJB和Hibernate。
OJB的排除很容易做出,一是因为它的文档太简单,太少;二是因为OJB计划下一个版本全面支持JDO,它的API会有重大变动,所以现阶段学习OJB是个错误,等它的API稳定了以后再学习不迟。
Hibernate的发现是很偶然的事情,只是在别人提到JDO的产品中,附带提了提而已,但当我开始研究Hibernate之后,我发现终于找到了我梦寐以求的ORM了。
Hibernate 完全符合我上面提到的标准之外,也解决掉了JDO的所有缺陷,而且方式之优雅令人赞叹。Hibernate的文档也是非常非常有特色的地方,它不仅仅是 Hibernate的功能介绍那么简单,它实际上是一个持久层设计的最佳实践的经验总结,文档里面的例子,文档里面的总结全部都是最佳设计的结晶。我认真的把Hibernate读下来的感觉就是,不单单把Hibernate掌握住了,而且对持久层的设计的经验都长了一大块,以前可从来没有觉得持久层的设计还有那么多的学问,也由此感觉到Gavin绝对是一个大牛人。
当然选择Hibernate最最重用的原因是Hibernate是一个我能够完完全全驾驭的了的软件。Hibernate的源代码非常少,而且写的非常简洁,我总觉得挺奇怪的,这么少的源代码能够实现这么多的功能,是个奇迹。 Hibernate的源代码树分的很清楚简单,源代码很易读,我一旦碰到文档中没有讲到的问题,或者文档中提到但是我搞不清楚的地方,我就去源代码中找,所有的问题都豁然开朗,而且让我对Hibernate的运行原理和细节搞的特别清楚,好像Hibernate就像自己写的代码一样,很清楚的知道,怎么写程序可以让Hibernate运行效率最高,最省内存,程序出了错误,很清楚的知道是什么地方的问题,怎么解决。所以用Hibernate让我特别放心,我能够驾驭它,而不像那些过于复杂的软件,本身框架就复杂的很,再加上不开源,出了问题也不知道怎么回事。
如果你认真看看Hibernate文档,就应该知道Hibernate支持集群。但是在集群操作下有一些限制,例如不能使用read-write cache等。
10亿的单子确有其事。我不觉得Hibernate用在大项目中有什么奇怪的,本质上就是JDBC的一个轻量级封装而已,如果你能在大单子中用JDBC,又为什么不能用Hibernate呢?反到是大单子用CMP太危险了。
发表评论
-
hibernate抓取策略
2012-04-20 09:58 1293Hibernate3 定义了如下几种抓取策略: 连接抓取( ... -
BLOB和CLOB的区别以及在ORALCE中的插入和查询操作
2012-04-09 12:59 1570ORACLE中的大对象: LONG: 可变长的字符串数据,最 ... -
Spring中关于SqlRowSet的Invalid scale size. Cannot be less than zero异常处理
2012-03-28 13:10 3788在使用Spring中使用JdbcTemplate.queryF ... -
hibernate open session in view 抛出异常解决方法
2012-03-23 20:52 1187http://www.blogjava.net/dreamst ... -
jdbcTemplate使用总结1
2011-09-20 15:16 1366SqlRowSet rs = jdbcTemplate.que ... -
java.lang.String 与string
2011-06-24 15:58 1032个人认为string应该是java.lang.String与数 ... -
hibernate一对多sort和order by
2011-04-15 09:23 15711. 從資料庫的觀點 ... -
Hibernate对集合排序
2011-04-15 09:19 1713Hibernate对集合中的元素支持两种排序方式: Ø 在数 ... -
Hibernate之deleted object would be re-saved by cascade 异常的解决
2011-02-24 11:31 936以下是我在网上找到的, 我用了第二种方法,奇怪的是: 我在ac ... -
Hibernate学习笔记
2011-02-12 16:25 1245HQL 注意事项: 1.请把以前sql中的表名换成类名,把字 ... -
hql 多表查询
2011-01-20 18:19 1143String sql = "select test1 ... -
拼接字符串的学习
2010-12-22 21:58 946package com.ccid.str; import j ... -
[原创]多条件模糊查询的通用代码
2010-12-22 18:31 1507str_query1 = "se ... -
Hibernate中使用Hql查询出一定时间段的记录【 Date 比较】
2010-12-22 18:30 20009// 初步过滤出符合条件的区域ID String sql = ... -
Hibernate 中 UUID.HEX的实现机制??
2010-11-26 10:13 3590Hibernate主键生成方式 Key ... -
HQL中修改对象属性的句子
2010-05-20 15:54 2087def newInstance = Organization. ...
相关推荐
Hibernate.jar包,Hibernate可以应用在任何使用JDBC的场合,包含 hibernate-commons-annotations-4.0.1.Final.jar hibernate-core-4.1.12.Final.jar hibernate-ehcache-4.1.12.Final.jar hibernate-entitymanager-...
赠送jar包:hibernate-jpa-2.1-api-1.0.2.Final.jar; 赠送原API文档:hibernate-jpa-2.1-api-1.0.2.Final-javadoc.jar; 赠送源代码:hibernate-jpa-2.1-api-1.0.2.Final-sources.jar; 赠送Maven依赖信息文件:...
《深入理解Hibernate配置与映射:hibernate-configuration-3.0.dtd与hibernate-mapping-3.0.dtd解析》 在Java世界里,Hibernate作为一款强大的对象关系映射(ORM)框架,极大地简化了数据库操作。而`hibernate-...
赠送jar包:hibernate-jpa-2.1-api-1.0.2.Final.jar; 赠送原API文档:hibernate-jpa-2.1-api-1.0.2.Final-javadoc.jar; 赠送源代码:hibernate-jpa-2.1-api-1.0.2.Final-sources.jar; 赠送Maven依赖信息文件:...
首先,我们要理解这个压缩包的核心内容。"index.html"是网页索引文件,通常用于展示插件的介绍和使用指南;"content.jar"和"artifacts.jar"则是包含插件的类库和资源,是插件运行的基础;"site.properties"和"site....
《Hibernate 5.2.10.Final:深入解析企业级Java持久化框架》 Hibernate,作为Java领域中广泛使用的对象关系映射(ORM)框架,一直以来都是开发人员的重要工具。5.2.10.Final是Hibernate的一个稳定版本,它在前一...
hibernate-jpa-2.1-api-1.0.0.final-sources.jar 源码 hibernate-jpa-2.1-api-1.0.0.final-sources.jar 源码
1. **实体管理**:Hibernate通过@Entity注解将Java类映射为数据库表,通过@Id指定主键,使得对象可以直接对应到数据库记录。 2. **配置**:Hibernate的配置文件(如hibernate.cfg.xml)中需要设置数据库连接信息、...
【标题】"hibernate-release-4.1.4" 是Hibernate框架的一个版本发布,具体为4.1.4.Final。Hibernate是一个开源的对象关系映射(ORM)框架,它允许Java开发人员在处理数据库时使用面向对象的概念,极大地简化了数据库...
hibernate-release-5.0.7.Final压缩包 -document -lib -project 内部Hibernate依赖库: antlr-2.7.7.jar dom4j-1.6.1.jar geronimo-jta_1.1_spec-1.1.1.jar hibernate-commons-annotations-5.0.1.Final.jar ...
Hibernate Tools是开发者在使用Hibernate框架进行Java应用程序开发时的重要辅助工具,它为Eclipse IDE提供了强大的集成支持,包括对象关系映射(ORM)的可视化设计、逆向工程、数据库生成、HQL和SQL查询编辑等功能。...
在本文中,我们将深入探讨`hibernate-commons-annotations-5.0.1.Final.jar`的源码,了解其内部结构和主要功能。 一、元数据注解 HCA的核心在于提供了一系列的注解,如`@Entity`、`@Table`、`@Column`、`@Id`等,...
hibernate-jpa-2.0-api-1.0.1.Final-sources.jar hibernate jpa 源代码
很多人为了配置jpa找这个动态产生字节码的jar文件,hibernate-distribution-3.3.1.GA包太大,而hibernate-distribution-3.3.2.GA的jar没有这个jar文件,希望对大家有用
hibernate-jpa-2.0-api-1.0.1.Final.jar
在本文中,我们将深入探讨Hibernate Validator 5.0.0.CR2版本,并了解如何将其引入到我们的项目中。 首先,"hibernate-validator-5.0.0.CR2-dist.zip" 是Hibernate Validator的一个发行版压缩包,其中包含了该版本...
在这个`hibernate-release-5.0.7.Final`版本中,包含了所有相关的jar包,为开发者提供了一个完整的Hibernate ORM解决方案。 在Java开发中,jar(Java Archive)包是Java类库的打包形式,它包含了一系列的类文件和...
hibernate-core-5.4.24.Final.jar
在"hibernate3-log4j-slf4j"的场景中,我们通常会将SLF4J作为日志接口,然后使用Log4j作为具体的日志实现。SLF4J提供了一个桥接器(slf4j-log4j12.jar),使得Log4j可以被SLF4J调用。这样做的好处是保持代码的独立性...