1. 复杂的实体状态
3种实体状态的设计是种种复杂性问题的根源。在持久化状态下不需要save就自动同步到数据库既无必要又容易造成烦恼。
2.Lazy Load 与 Eager Load
Lazy Load的概念听起来不错,用起来就不那么妙了,也直接导致产生了Open Session In View这种妥协方案。此外,在domain类中定义的FetchType只针对get/load/loadAll有效,对Query是无效的,需要再次定义。
3. Open Session In View
Lazy Load引发的一个有较多副作用的解决方案。
4.级联
级联是一个很好很OO的概念,但往往增加了复杂度。
5.批量更新与缓存不一致
Hibernate引入了一级缓存和二级缓存,提供了性能的同时带来了缓存一致性的问题。批量更新或者其他系统对数据库的更新容易造成缓存不一致。
6.配置繁琐
Hibernate最初只能使用xml进行配置,后来终于引入了Annotation和CoC(约定优于配置)来简化配置,但这种变革并不彻底。Hibernate默认把userName映射userName,但实际开发中,把userName映射为user_name的情况更多些。
7. HQL
HQL是一个类SQL对象查询语言,但正是因为HQL与SQL的相似性,往往容易造成混淆,同时HQL难以调试,本质创建了一种语言,增加学习成本。
8. 太多的查询方案
HQL、QBC、SQL,就不能统一点,简洁点?
9. N+1次查询
10. 性能问题
总之,Hibernate立足于作一个完整的自动化的能够适应各种环境的ORM,因此带来了100%的复杂性。但我们实际需要的只是一个简单的能够以20%时间解决80%问题的框架,具有对象-关系映射,能自动生成SQL,能够让新手尽快工作就足够了,也许ActiveRecord是一个选择。
|
Hibernate的十大罪状
最新推荐文章于 2024-08-16 15:17:01 发布