于 2004-09-22 17:46
一、Hibernate是JDBC的轻量级的对象封装,它是一个独立的对象持久层框架,和App Server,和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合,例如Java应用程序的数据库访问代码,DAO接口的实现类,甚至可以是BMP里面的访问数据库的代码。从这个意义上来说,Hibernate和EB不是一个范畴的东西,也不存在非此即彼的关系。
二、Hibernate是一个和JDBC密切关联的框架,所以Hibernate的兼容性和JDBC驱动,和数据库都有一定的关系,但是和使用它的Java程序,和App Server没有任何关系,也不存在兼容性问题。
三、Hibernate不能用来直接和Entity Bean做对比,只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看,Hibernate也是做为JDBC的替代者出现的,而不是Entity Bean的替代者出现的,让我再列一次我已经列n次的框架结构:
传统的架构:
1) Session Bean <-> Entity Bean <-> DB
为了解决性能障碍的替代架构:
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提高上面架构的开发效率的架构:
3) Session Bean <-> DAO <-> Hibernate <-> DB
就上面3个架构来分析:
1、内存消耗:采用JDBC的架构2无疑是最省内存的,Hibernate的架构3次之,EB的架构1最差。
2、运行效率:如果JDBC的代码写的非常优化,那么JDBC架构运行效率最高,但是实际项目中,这一点几乎做不到,这需要程序员非常精通JDBC,运用Batch语句,调整PreapredStatement的Batch Size和Fetch Size等参数,以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。
3、开发效率:在有JBuilder的支持下以及简单的项目,EB架构开发效率最高,JDBC次之,Hibernate最差。但是在大的项目,特别是持久层关系映射很复杂的情况下,Hibernate效率高的惊人,JDBC次之,而EB架构很可能会失败。
4、分布式,安全检查,集群,负载均衡的支持
由于有SB做为Facade,3个架构没有区别。
四、EB和Hibernate学习难度在哪里?
EB的难度在哪里?不在复杂的XML配置文件上,而在于EB运用稍微不慎,就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题,需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作,程序员的大部分精力都被放到了EB的性能问题上了,反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。
Hibernate难在哪里?不在Hibernate本身的复杂,实际上Hibernate非常的简单,难在Hibernate太灵活了。
当你用EB来实现持久层的时候,你会发现EB实在是太笨拙了,笨拙到你根本没有什么可以选择的余地,所以你根本就不用花费精力去设计方案,去平衡方案的好坏,去费脑筋考虑选择哪个方案,因为只有唯一的方案摆在你面前,你只能这么做,没得选择。
Hibernate相反,它太灵活了,相同的问题,你至少可以设计出十几种方案来解决,所以特别的犯难,究竟用这个,还是用那个呢?这些方案之间到底有什么区别呢?他们的运行原理有什么不同?运行效率哪个比较好?光是主键生成,就有七八种方案供你选择,你为难不为难?集合属性可以用Set,可以用List,还可以用Bag,到底哪个效率高,你为难不为难?查询可以用iterator,可以用list,哪个好,有什么区别?你为难不为难?复合主键你可以直接在hbm里面配置,也可以自定义CustomerType,哪种比较好些?你为难不为难?对于一个表,你可以选择单一映射一个对象,也可以映射成父子对象,还可以映射成两个1:1的对象,在什么情况下用哪种方案比较好,你为难不为难?
这个列表可以一直开列下去,直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候,你会觉得幸福呢?还是悲哀呢?如果你是一个负责的程序员,那么你一定会仔细研究每种方案的区别,每种方案的效率,每种方案的适用场合,你会觉得你已经陷入进去拔不出来了。如果是用EB,你第一秒种就已经做出了决定,根本没得选择,比如说集合属性,你只能用Collection,如果是Hibernate,你会在Bag,List和Set之间来回犹豫不决,甚至搞不清楚的话,程序都没有办法写。
• 小菜虫wes109 , 请进.
一、Hibernate是JDBC的轻量级的对象封装,它是一个独立的对象持久层框架,和App Server,和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合,例如Java应用程序的数据库访问代码,DAO接口的实现类,甚至可以是BMP里面的访问数据库的代码。从这个意义上来说,Hibernate和EB不是一个范畴的东西,也不存在非此即彼的关系。
二、Hibernate是一个和JDBC密切关联的框架,所以Hibernate的兼容性和JDBC驱动,和数据库都有一定的关系,但是和使用它的Java程序,和App Server没有任何关系,也不存在兼容性问题。
三、Hibernate不能用来直接和Entity Bean做对比,只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看,Hibernate也是做为JDBC的替代者出现的,而不是Entity Bean的替代者出现的,让我再列一次我已经列n次的框架结构:
传统的架构:
1) Session Bean <-> Entity Bean <-> DB
为了解决性能障碍的替代架构:
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提高上面架构的开发效率的架构:
3) Session Bean <-> DAO <-> Hibernate <-> DB
就上面3个架构来分析:
1、内存消耗:采用JDBC的架构2无疑是最省内存的,Hibernate的架构3次之,EB的架构1最差。
2、运行效率:如果JDBC的代码写的非常优化,那么JDBC架构运行效率最高,但是实际项目中,这一点几乎做不到,这需要程序员非常精通JDBC,运用Batch语句,调整PreapredStatement的Batch Size和Fetch Size等参数,以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。
3、开发效率:在有JBuilder的支持下以及简单的项目,EB架构开发效率最高,JDBC次之,Hibernate最差。但是在大的项目,特别是持久层关系映射很复杂的情况下,Hibernate效率高的惊人,JDBC次之,而EB架构很可能会失败。
4、分布式,安全检查,集群,负载均衡的支持
由于有SB做为Facade,3个架构没有区别。
四、EB和Hibernate学习难度在哪里?
EB的难度在哪里?不在复杂的XML配置文件上,而在于EB运用稍微不慎,就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题,需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作,程序员的大部分精力都被放到了EB的性能问题上了,反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。
Hibernate难在哪里?不在Hibernate本身的复杂,实际上Hibernate非常的简单,难在Hibernate太灵活了。
当你用EB来实现持久层的时候,你会发现EB实在是太笨拙了,笨拙到你根本没有什么可以选择的余地,所以你根本就不用花费精力去设计方案,去平衡方案的好坏,去费脑筋考虑选择哪个方案,因为只有唯一的方案摆在你面前,你只能这么做,没得选择。
Hibernate相反,它太灵活了,相同的问题,你至少可以设计出十几种方案来解决,所以特别的犯难,究竟用这个,还是用那个呢?这些方案之间到底有什么区别呢?他们的运行原理有什么不同?运行效率哪个比较好?光是主键生成,就有七八种方案供你选择,你为难不为难?集合属性可以用Set,可以用List,还可以用Bag,到底哪个效率高,你为难不为难?查询可以用iterator,可以用list,哪个好,有什么区别?你为难不为难?复合主键你可以直接在hbm里面配置,也可以自定义CustomerType,哪种比较好些?你为难不为难?对于一个表,你可以选择单一映射一个对象,也可以映射成父子对象,还可以映射成两个1:1的对象,在什么情况下用哪种方案比较好,你为难不为难?
这个列表可以一直开列下去,直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候,你会觉得幸福呢?还是悲哀呢?如果你是一个负责的程序员,那么你一定会仔细研究每种方案的区别,每种方案的效率,每种方案的适用场合,你会觉得你已经陷入进去拔不出来了。如果是用EB,你第一秒种就已经做出了决定,根本没得选择,比如说集合属性,你只能用Collection,如果是Hibernate,你会在Bag,List和Set之间来回犹豫不决,甚至搞不清楚的话,程序都没有办法写。
• 小菜虫wes109 , 请进.
作者 | Re:Hibernate的优点 [Re:lummyliao] |
didongusa 发贴: 61 积分: 0 | The EJB components are managed by EJB container, so who manage the Hibernate objects? In Framework 1, for BMP, the JDBC is wrapped by EJB container as DS, they are transparent to clients, now the Hibernate is going to replace JDBC, where I deploy them to? I do appreciate your help. Thanks. • Google的[ 翻译此页 BETA ]!!!!!!!!!!!!! |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
dengyin2000 发贴: 18 积分: 0 | 他并不需要容器manage 象一般的容器就可以 tomcat 你可以搞个简单的hibernate 例子 试试看 • eclipse folding plug-in |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
didongusa 发贴: 61 积分: 0 | If you need Tomcat, that means the Hibernate objects still need container. I confused the Tomcat was used for holding Servlets, I just guess they don't manage Hibernate objects. For example, I have a table called "Test" with one colume: "col1" datatype is "varchar2(100)". The database is in a remote node. Currently I have a node, this is my EJB container, I have a stateless session bean with remote "Hello", and the bean class is "HelloBean". I need to implement a business method named: "public void hello (String s)" inside "HelloBean" and exposed to "Hello", when client invoke 'hello("Hello World.");', I want to insert one row of data "Hello World." into the table "Test". My first question is: The Hibernate has hundreds classes, where I put those library classes? If the EJB container have to know all the classes. My second question is: If I need JDBC connection from public void hello(String s) { // JDBC needed here to insert. } How I get the "Connection" object? Thanks. I just interested to know how the links are implemented: 3) Session Bean <-> DAO <-> Hibernate <-> DB • eclipse folding plug-in |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
didongusa 发贴: 61 积分: 0 | I only need the idea where to find the Hibernate objects from the bean. Thanks. • 美军士兵手册(有何感想?) |
作者 | Re:Hibernate的优点 [Re:didongusa] |
nothing 我等待.. CJSDN高级会员 发贴: 1572 积分: 13 | 灵活的东西,不适合于工业生产. Best Regards, "But he has NOTHING on........." • 张孝祥java8碟 好东西啊 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
sankxuan 发贴: 36 积分: 0 | 楼主转载请说明,hibernate的优势是显而易见的,如果有任何问题, 请参看hibernate的文档,ejb3.0的也是吸取了hibernate的很多的东 西 • 请问哪儿有JAVA ——API 下载? |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
didongusa 发贴: 61 积分: 0 | In the 3) Session Bean <-> DAO <-> Hibernate <-> DB Who is going to implement the DAO? Really need someone's help? • Google的[ 翻译此页 BETA ]!!!!!!!!!!!!! |
作者 | Re:Hibernate的优点 [Re:didongusa] |
gispda 发贴: 22 积分: 1 | didongusa wrote: Firstly,You'd better to bind a sessionfactory to your app server,then in your session Bean can get the sessionfactory ,then you can put it in your dao. You dao can do all the CRUD operation. Session Bean's bussness method is your Dao's caller. • IBM还真是牛啊 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
didongusa 发贴: 61 积分: 0 | Looks like you have to write some startup files to create the sessionfactory objects and bind them at the server startup. If shutdown and restart the server is impossible, how can you create and bind the object? Thanks. • 一个孩子纯洁的心——一个令医生目瞪口呆的孩子[zt] |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
didongusa 发贴: 61 积分: 0 | Using the "T3StartupDef" to trigger the binding at startup could hurt the portability, I think this is no no. Another way? Thanks. • 一个孩子纯洁的心——一个令医生目瞪口呆的孩子[zt] |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
gispda 发贴: 22 积分: 1 | okay.then you can use spring with hibernate. • 别以为装机容易! |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
极品飞车 发贴: 134 积分: 3 | 咋都说英文了?用spring+hibernate 吧. • 请问哪儿有JAVA ——API 下载? |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
didongusa 发贴: 61 积分: 0 | This container is too cold, you need a warmer one? Hibernate means "sleep inside the ejb container"? • 只有2%的人回答得了这道题 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
huzhigang 发贴: 4 积分: 0 | hibernate会困难到让你这么难选择?我表示惊讶。 实际上是实体bean让我们很难选择的。 “ 这个列表可以一直开列下去,直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候,你会觉得幸福呢?还是悲哀呢?如果你是一个负责的程序员,那么你一定会仔细研究每种方案的区别,每种方案的效率,每种方案的适用场合,你会觉得你已经陷入进去拔不出来了。如果是用EB,你第一秒种就已经做出了决定,根本没得选择,比如说集合属性,你只能用Collection,如果是Hibernate,你会在Bag,List和Set之间来回犹豫不决,甚至搞不清楚的话,程序都没有办法写。 ” Bag,List,Set的选择很容易,甚至不需要用一分钟。在不同的场合需要不同的解决问题的方式,这不好嘛? 相反,EJB面对所有问题的all-in-one方式似乎是让你不用选择,但也让你无法选择合适的解决方案。 如果楼主愿意浪费你三天的宝贵时间看完hibernate到底是什么?我相信你会喜欢它而不是ejb。 • IBM还真是牛啊 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
holylz2004 发贴: 3 积分: 0 | DAO是什么啊, • myeclipse 3.82 的中文问题 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
dlint 发贴: 10 积分: 0 | The book "expert one-one-one J2EE Development without EJB" by Rod Johnson covers all the topics above. David Lin J2EE Consultant Melbourne • 服务器软件升级,激活JNI功能 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
jbwang 发贴: 201 积分: 4 | 有的事情不能说的那么绝对! 多方面看问题。 MyJ2EE.grow(); System.exit(0); • 只有2%的人回答得了这道题 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
yclc 发贴: 22 积分: 0 | 其实类似的争论在很多方面出现了,你们彼此间的争论和讨论JAVA和C++孰优孰劣有什么区别呢?一种设计模式存在必然有他的存在理由,争个半天还不于自己去体验下~~ • 服务器软件升级,激活JNI功能 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
findjob 发贴: 19 积分: 0 | >>2、运行效率:如果JDBC的代码写的非常优化,那么JDBC架构运行效率最高但 >>是实际项目中,这一点几乎做不到,这需要程序员非常精通JDBC,运用Batc语 >>句,调整PreapredStatement的 Batch Size和Fetch Size等参数,以及在必的 >>情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此 >>Hibernate架构表现出最快的运行效率。 EB的架构效率会差的很远。 不明白为什么preparedStatement的效率会高? PreparedStatement pstmt = conn.preparedStatement(......); for (int i=0;i<size;i++) { pstmt.setString(1,...); pstmt.addBatch(); } pstmt.executeBatch(); 用PreparedStatement.addBatch()有什么用?在mysql的驱动中只是把循环放在了 pstmt.executeBatch()而已,原来要往数据庫端发送多少次封包,用了Batch还是要多少次,性能一点改变也没有。我还不如果动态生成语句,然后向数据庫端发送一次封包。 • 急聘WEB报表开发人员(北京兼职),懂IReport报表工具 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
robbin 发贴: 3 积分: 0 | 大言不惭!你自己写个简单的例子测试一下两种方式的插入1000条数据的效率就会明白你现在说的这些话多么可笑了。 • 小菜虫wes109 , 请进. |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
findjob 发贴: 19 积分: 0 | 没试过我不会乱说,我插入10万条,两者差距只有3秒。 你有试过吗?没有吧。 你有看过mysql jdbc的驱动吗,看过再说。 • 只有2%的人回答得了这道题 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
findjob 发贴: 19 积分: 0 | 这是我的测试 mysql4.0.18nt mysql-connector-java-3.1.4-beta-bin.jar window server 2003 代码:
findjob edited on 2004-10-22 19:37
• IDEA 4.5.3已经发布了。 |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
findjob 发贴: 19 积分: 0 | 10000条 • “FlashPaper”把Word文件转换成Flash |
作者 | Re:Hibernate的优点 [Re:lummyliao] |
findjob 发贴: 19 积分: 0 | robbin是吗,是不是Hibernate.org.cn上的robbin,我知道你很精通Hibernate,你是牛人。但这次你绝对错了。如果用的是mysql. |