使用hibernate的11大优势
发布网友
发布时间：2023-07-08 10:15
共1个回答
热心网友
时间：2024-09-30 02:17
Hibernate在解决性能问题方面做得非常好 有了它的缓存机制 使用第三方缓存和数据库连接池 就较好的解决的性能问题 但这些还不够 hibernate给了开发者足够的自由 让开发者自己去控制性能问题
学习了一段时间的ibatis 我觉得hibernate有着ibatis无法替代的优势
开发者都知道 hibernate让我们以oo的方式操作数据库 这让我们看到了hibernate的强大之处 体验到操作数据的方便 但Gavin King说 hibernate最耀眼之处是hibernate的缓存机制 而不是以oo的方式操作数据库 Hibernate的缓存机制不外乎是一级缓存session 二级缓存sessionFactory 和第三方缓存如ehcache 也就是hibernate的最强大的地方是它的缓存 理解了这个才能真正的理解hibernate 缓存实在太难了 我至今未能真正理解
可维护性 ibatis宣扬写sql语句 它将sql语句放进一个单独的xml文件 这种方式赢得了很多开发者的喜爱 一句话 方便维护 但hibernate同样具有这种功能 而且比ibatis更加强大 Hibernate的命名查询/命名参数查询 就是将hql语句放在一个单独的xml文件之中 它仍然让人们以面向对象的方式去操纵数据 这得到大量遵循oo方式开发者的喜爱 而不用在以oo的方式写着代码的同时 然后再转变思维 用面向关系的方式去写那些sql语句 但hibernate不仅做了这些 它的native sql查询方式 完全满足sql语句的偏爱者 它像ibatis一样 将sql语句放在配置文件之中
性能 我坚信 hibernate性能问题不是问题 想想那么多大中小项目都在使用hibernate 你还怀疑hibernate的性能吗？spring整合hibernate之后 在真正性能瓶颈的地方 完全可以使用spring集成的jdbc 或直接写存储过程得了 但首先得确认 这实在是性能瓶颈的地方 我想 不应想当然的认为性能的问题 所谓的性能问题阻挠了很多人
我认为 性能的好坏无外是发送sql语句的多少而已 性能好 发送的sql语句少 性能差 就是发送大量的sql语句 Hibernate在解决性能问题方面做得非常好
有了它的缓存机制 使用第三方缓存和数据库连接池 就较好的解决的性能问题
但这些还不够 hibernate给了开发者足够的自由 让开发者自己去控制性能问题
我认为开发者可以在以下几个方面自行调优
a 在查询字符串中 应该总是使用jdbc的占位符？ 或使用使用命名参数 不要自查询中使用字符串值来代替非常量值
b Flush会影响性能 频繁刷新影响性能 尽量减少不必要的刷新
c Cascade策略 在几对几的关系 正确设置cascade策略 想清楚在操作对象A的同时是否需要级联操作对象B 比如在one to many的父子关系中 删除了父亲one 需级联删除子many 这时的one这端可设置cascade = delete 这样在删除one时 会自动删除子 但对子的操作不会影响父 Cascade还有其他的属性值 只要设置正确 可提升性能
d lazy策略 正确设置延迟加载策略同样会提升性能 在one to many或many to many中 通常总应该延迟加载many的一方的到内存 设置了lazy = true 首先发送sql语句 加载自己到内存 到需要时才加载级联对象 lazy= false 则会同时加载自己和级联对象到内存
e 另外还有集合的性能（set list map array） 都应正确设置
f 正确使用第三方缓存 在读操作频繁写操作不多的情况 使用第三方缓存可大幅度提升性能 如ehcache的缓存策略有 read only read write和notstrict read write
f 随着hibernate新版本的发布 和技术的发展 我相信hibernate的性能会越来越好 所有性能不是不使用hibernate的原因
hibernate不仅仅作为持久层的orm框架存在 它除了层的持久化操作外 还有很多
在注解annotation已经走向主流的今天 hibernate 迅速响应 让xml部署描述符成为可选的 Hibernate annotation 对大字段的处理只是一个@Lob就搞定了
hibernate search对Lucene进行了轻量级的封装 全文检索变得非常简单
Hibernate validator被认为是最合理的验证方式 将验证策略直接附在贯穿各层的领域模型domain上 不再需要哪些web框架的xml方式的验证 代码中不再出现大量的非空/null的判断
jbpm Jbpm业务流程引擎的持久层采用hibenrnate来实现 要想使用jbpm hibernate是必须的 我想 业务流程管理无比重要 在soa迅速发展的今天 如果实施soa项目 业务流程管理是必然和必须的 因为soa就是业务和it技术的融合 是业务流程管理和it基础架构的融合 在soa中 业务管理是第一位的 这需要相应的技术来实现该业务流程管理 开源领域的jbpm我想会是首选 所以 为了将来有可能实施soa项目 为了实现soa的业务流程管理 应该使用hibernate
大家都知道 hibernate将ejb 时代的实体bean赶进了历史 而ejb 的jpa标准也只不过是hibernate的子集而已 jsr规范请求的威力是巨大的 没有各种jsr规范请求 就不会有各种应用程序框架 各种应用程序框架只是那些jsr规范请求的实现者 jpa作为持久层的规范标准 引导持久层orm框架的方向 jpa同样以面向对象的方式操作数据库 而不是写sql语句 规范标准都完全orm 不写sql了 你还有理由不跟着它吗？
Spring+hibernate+范型+可变参数 这是一个非常强大的组合 对应普通的crud操作 你不再需要重复写那些烦人的相似的层和manager层的代码 仅仅需要写一次 就完成了所有大量的crud操作 Ibatis尽管也支持范型 但始终没有hibernate支持的好
Jboss hibernate是jboss的项目 jboss的所有项目的持久层都采用的hibernate 要知道 jsr规范组的专家们大多数是来自jboss的 在一定程度上说 jboo引领着java的发展方向 使用hibernate 跟着jboss 不偏离java的发展方向
Gavin King 我最崇拜的偶像 他不仅发明了强大的hibernate 还搞出了同样强大且优雅的web 应用程序框架seam 他是ejb 专家组成员之一 是jpa规范请求的领导者 他java领域最有发言权 最权威的领袖人物之一 现在 他领导web bean的 jsr 的发展 web bean规范的制定 全球软件巨头如ibm oracle bea和apache没有一个反对 纷纷响应 Web bean 想象起来 实在太美好了 完全的松耦合和强类型 所有的应用组件生活在一个应用组件上下文context中 相互合作 那时将不再有各种各样的上下文环境 不再有struts 的ActionContext 不再有spring的ApplicationContext 不再有hibernate的session 不再有持久化上下文 不再有事务上下文 不再有安全上下文 所有组件生活在一个大家庭中 大家其乐融融 实现天下的大和平
osgi 我认为现在最值得学习的一个技术 有了osgi 实现真正的多模块开发 改变传统的开发方式 现在 已经有了hibernate osgi spring dynamic mol（osgi） struts 同样实现了对osgi的支持 目前 eclipse是基于osgi开发的 ibm的websphere v bea的所有产品都重构在osgi上 spring的应用服务器同样基于osgi 在EclipseCon 上 osgi成为了主要的话题 Osgi受到如此的待遇 一点不奇怪 因为他具有无比强大的功能 改变传统的软件开发方式 Osgi采用树设计模式 将一个项目分成多个模块（bundle） 每个模块单独部署 单独运行 说白了 就是将一个工程分成许多的插件 每个插件单独开发 重复使用 实现完全的即插即用 太令人激动了 如果公司的软件开发基于osgi 将会有大量的重复使用的osgi bundles 公司将会积累大量的无形资产 软件开发将会越来越快 而ibatis现在还没见到对osgi的支持
hibernate的社区非常繁荣 ibatis则相对平静
综述 hibernate还有很多优秀的特点 只是我们不知道 Hibernate与ibatis 就像大家闺秀对小家碧玉 大家闺秀不仅具有小家碧玉的全部 而且知名度更高 更受尊敬 更受人追捧 更有发展前途 小家碧玉尽管也很有魅力 但始终比上大家闺秀
Hibernate所做的不仅仅是层的持久化工作 而ibatis恰恰如此
选择hibernate 选择orm的王者 选择更全面的工作体验 选择更高效的工作方式 选择更多的利润 选择Gavin King 跟着领袖走 选择jboss 追随开源的潮流 不偏离java的发展方向
lishixin/Article/program/Java/ky/201311/28357