|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2007-12-14
用hibernate,还不如等数据库全面支持面向对象的数据库!
|
| 返回顶楼 | |
|
最后更新时间：2007-12-14
User.java, UserVO.java, UserDTO.java, UserFormBean 这么多个类,如果再加上类之间的关联关系,不能再用BeanUtils拷贝属性，会让人疯掉的。
|
| 返回顶楼 | |
|
最后更新时间：2007-12-14
感觉这个问题可以理解为
用水果刀削苹果好还是菜刀削苹果好 个人觉得，我需要的是能在最短时间内削出最好的苹果 我需要的是苹果而不是刀 所以如果你是个用菜刀高手，我会用你的 这个话题也可以牵涉到另一个问题 就是技术员如何跳出技术层面来想问题 |
| 返回顶楼 | |
|
最后更新时间：2007-12-14
中小型系统hibernate可以.
大型的还真要好好想想,多功能分布不同服务器(二级分布式cache性能行吗),OpenSessionInView行吗?这个要是不行lazyload还要意义吗? |
| 返回顶楼 | |
|
最后更新时间：2008-01-16
其实围绕Hibernate的话题，我都已经说过不下30遍，以致于最近两年以来，我对所有Hibernate的问题都不愿意再回应。另外最近一年多来，使用Rails的ActiveRecord，让我对ORM的认识又加深了很多，其实对于那么多争议的问题，最好的解决办法就是自己去实践。对于自己没有去实践过的东西，争是争不出来什么的。
引用 1、以数据库为中心建模 VS 以领域模型为中心建模： 老开发人员大多倾向于前者，因为比较符合过去的开发习惯，另外他们强调数据库的生命周期大于App 向我这样的只有几年工作经验的往往会倾向于后者，因为这能更充分发挥ORM的威力，更符合OO，免去很多维护DB的繁琐工作。 数据库设计三大范式如雷贯耳，但作为非科班出身的我直到两个月前竟然都不知道三大范式究竟是什么。那么三大范式是什么？ 引用 第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。
第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。 第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。 两个月前当我购买了一本《MySQL权威指南》，翻到三大范式的定义的时候，我内心巨震，三大范式简单总结一句就是消除冗余，单纯依赖关系。不允许数据库表出现冗余字段，不允许表之间多重依赖，因此符合三大范式设计的数据库模型其实和你按照面向对象思想去建模得到的数据库模型是一样的。 所以不论你是从数据库为中心建模，还是你以领域模型为中心建模，你应该最终得到一个一致的数据库模型。之所以导致数据库建模和OO建模的不一致，是因此传统的数据库建模从来都是违背三大范式的。而我们在过去经常说的一句话就是：为了数据库查询性能，我们需要多加一些冗余字段，不一定非要遵循三大范式...... 所以不要再说什么数据库设计和面向对象设计导致的数据模型冲突的话，不是他们冲突，是你违背了三大范式，自己制造出来的冲突。 引用 2、Hibernate VS iBatis/JDBC：
担心失去对SQL待控制权，导致不能做优化，DBA反对 Hibernate是在JDBC之上的又一层框架，因此想当然的认为其性能不如iBatis/JDBC（我认为这个结论不成立，因为引入一个ORM层给了我们更多机会去优化性能，比如一二级缓存、lazyload、查询缓存，并且方式更优雅）。参考为什么ORM性能比iBATIS好？ 担心OpenSessionInView模式有性能问题（http://www.javaeye.com/topic/17501） Hibernate无法应付复杂查询（我认为这不是问题，HQL和criteria查询能力很强，再不济还可以用SQL啊） JavaEye网站的数据库设计是面向对象为中心的设计，但是拿三大范式来衡量，大部分设计都是吻合的，而我们的数据库缓存命中率在90%左右。缓存服务器的流量是数据库服务器流量的2.5倍之多。事实上我们有很多地方的查询尽量避免join，宁可让他n+1，这样速度反而更快，缓存命中率更高。 例如我们现在把帖子的内容字段拆分出来，单独放在一个post_texts表里面。这样posts表实际上只有35MB，而post_texts表有1GB。每次显示一个post，都会用主键去load post_text，命中缓冲。不需要查数据库，不需要去碰那个1GB的大表。 要充分发挥ORM的缓存优势，就必须把表设计的尽量细颗粒度，消除冗余和多重依赖，最终可能是相当多的小表，表之间通过主外键关联，但是关联关系都是单一的。那么这种追求面向对象的数据库模型是非常符合三大范式的。 引用 3、对Hibernate等ORM框架能否胜任大型项目的怀疑：
其实项目大小不是技术选型的主要考虑，关键看项目类型，OLTP还是OLAP、广而浅型的还是窄而深型的、数据量大小等等，这些因素更能影响结果 我只想举一个例子，Google在使用Hibernate，并且Google开发了一个叫做Hibernate Shards的分布式工具，将Hibernate运用在大规模分布式数据库环境当中，Hibernate Shards现在也是开源的，在Hibnerate网站上面就可以找到文档 引用 4、Hibernate学习成本高 不可否认，相对于spring、struts，Hibernate是一个学习曲线陡峭的框架，但是我觉得综合考虑开发效率和长期收益，还是值得学习和采用的 有时候参考着看看Rails的ActiveRecord，你才能发现ORM的乐趣。横向对比一下，你的思路会开阔很多，认识也会客观一些。 推荐有空阅读我写的相关文章： 漫谈应用缓存的命中率问题 为什么ORM性能比iBATIS好？ 缓存简述 |
| 返回顶楼 | |
|
最后更新时间：2008-01-16
有一点必须承认，Hibernate虽然是一个功能非常强大的ORM，但是他在使用上面的陷阱也非常多，稍一疏忽就可能导致性能问题，所以真正把Hibernate用得好的项目非常罕见(当然也有用得好性能非常棒的)。即使是Rails的ActiveRecord，如果不注意，也很容易导致性能上面的问题，当然ActiveRecord功能简单的多，所以问题不像Hibernate那样突出。另外ActiveRecord的log输出的SQL非常易读，所以比较容易及时发现问题，不像Hibernate的log输出的SQL，根本就不是给人看的，出了问题很不容易发现。
我认识的很多相当资深的开发人员其实也不能够正确的认识ORM的作用，对Hibernate持相当否定的态度。我觉得这种状况一点都不奇怪，其实我自己也是在用了Rails的ActiveRecord，并且在JavaEye网站摸索了那么长时间，才对ORM能够有一个全面的认识的。 总之，follow your heart! 用你自己认为是正确的方式去实践和总结、不要理会别人的观点。 |
| 返回顶楼 | |
|
最后更新时间：2008-01-16
daquan198163 写道 2、Hibernate VS iBatis/JDBC： 担心失去对SQL待控制权，导致不能做优化，DBA反对 Hibernate是在JDBC之上的又一层框架，因此想当然的认为其性能不如iBatis/JDBC（我认为这个结论不成立，因为引入一个ORM层给了我们更多机会去优化性能，比如一二级缓存、lazyload、查询缓存，并且方式更优雅）。参考为什么ORM性能比iBATIS好？ 担心OpenSessionInView模式有性能问题（http://www.javaeye.com/topic/17501） Hibernate无法应付复杂查询（我认为这不是问题，HQL和criteria查询能力很强，再不济还可以用SQL啊） 这是一个老生常谈的问题，同时这也是一个盖棺定论的问题，很抱歉我忘记了是否是Clinton Begin（总之是iBATIS team中的一位开发者在TSS上）说过的话，如果你针对的是一个现存的DB系统，它并没有采用一个良好的模型设计。那么iBATIS将是你最好的选择，而如果你正在进行新的系统构架、设计和开发，同时你对数据库模型设计有着最高的话语权，那么Hibernate是你最好的选择。 任何一个优秀、成熟的系统架构师都会明白和认同这个道理：针对某个项目，没有最好的产品，只有最适合的。可能这个项目，我选择了iBATIS，下一个我就用了Hibernate，可能出于对技术的判定，也可能是因为对客户的屈从。 daquan198163 写道 3、对Hibernate等ORM框架能否胜任大型项目的怀疑： 其实项目大小不是技术选型的主要考虑，关键看项目类型，OLTP还是OLAP、广而浅型的还是窄而深型的、数据量大小等等，这些因素更能影响结果 任何时候人都是最主要的，那些应用了Hibernate而失败的项目，错误在人而非产品，每次我看到有人抱怨“哦，Hibernate就是一团狗屎，我们需要每天来重启web服务来满足用户”，这样的抱怨只能让我对他无奈。而Hibernate的成功应用数不胜数，Hibernate适用不了所有的项目，但是在大多数情况下他是目前java ORM产品无可替代的选择。 最后要说的，楼主标题中的定论是错误的，针对某个框架或者产品，所谓的定论只能让那些初学者更加的盲目和盲从，从而失去了自我判断的能力。针对自己的项目，进行自己的调查，做出自己的选择。这些才是最重要的。 Active Thinking is your best choice. |
| 返回顶楼 | |
|
最后更新时间：2007-12-14
以下针对“以数据库为中心建模VS以领域模型为中心建模”：
通常决定是否基于数据库设计和基于领域模型设计取决于你的分析结果——分析模型。 众所周知：数据库设计基于两种设计粒度：表和字段； 如果分析模型和数据库存在如下差异，则应当考虑采用领域模型： 1. 表粒度所能提供的结构化能力无法支持分析模型，比如一个分析模型的数据是分布在多张表中，或者一张表中表示的分析模型有多种（即ORM所支持的几种继承能力，以及component） 2. 字段粒度无法支持分析模型的逻辑计算，存在较多逻辑计算依赖多个字段甚至是不定字段。 如果以上两种情况都满足，那么采用领域模型设计，无疑拥有较好的设计开发成本，同时设计和分析的差异性在较小范围内，沟通成本也将保持较低的范围内。 其它方面不多说； Robbin提供有关性能的经验非常值得借鉴。 |
| 返回顶楼 | |
|
最后更新时间：2007-12-14
很喜欢Robbin的文章，如果能出本j2ee之类的书，我一定跟进
|
| 返回顶楼 | |
|
最后更新时间：2007-12-14
数据库设计得不够OO，甚至根本就是没考虑过OO。
不适合用Hibernate？ PS：写书有风险，著书要谨慎.... |
| 返回顶楼 | |
