|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-09-19
什么都是优点的东西不可能存在， 又优点了，相比之下必会产生缺点。
甚至说，这些优点和缺点到底是不是优点和缺点，也是随着时间地点人物在变化的。 |
| 返回顶楼 | |
|
发表时间：2006-09-19
downpour 写道 Hibernate在查询时，面对很多映射有时候显得很苍白。
例如有个业务场景，Department和Employee是一对多关系。现在我对Department进行分页查询，要求在显示的页面上同时显示每个Department中Employee的数量。这是一个很简单的业务场景，但是想象一下如何用hibernate进行映射？ 首先否定一种做法：hql：FROM Department department。然后针对每个department，去做department.getEmployees().size()。这样不仅会发送n＋1条SQL，而且性能太低。 我们肯定希望采用一句HQL解决问题，但是此时问题来了，当你试图做SELECT department, count(employee.id) FROM .....这样的HQL时，在Java端，发现没有一个合适的对象可以映射。 从OO的角度，其实可以在Department这个类中加一个employeeSize来表示这种业务场景。但是好像Hibernate无法去做类似的映射。而iBatis在这个方面却灵活的多。 在Department中做个formula映射来计算Employee的数量，当然，你的数据库要支持子查询，性能应该还可以接受。 |
| 返回顶楼 | |
|
发表时间：2006-09-20
庄表伟 写道 记得以前robbin还说过，Hibernate生成的SQL，非常的优化，效率极高，非JDBC顶级高手，勿须尝试写出比Hibernate更加好的SQL。
怎么现在就成了：“现在极其厌恶Hibernate生成的SQL，又臭又长，极难阅读。”？ Robbin在制造话题，哈~ |
| 返回顶楼 | |
|
发表时间：2006-09-20
不仅仅是制造话题,是有了新宠(ActiveRecord),忘了旧爱(Hibernate)..
|
| 返回顶楼 | |
|
发表时间：2006-09-21
没用过HQL，本来没有发言的权利，可还是忍不住想说两句。
一、OO或者不OO根本不是要考虑的问题。现在都流行DSL，还要死守着OO不放么？什么语言对了特定领域的味道，就用什么语言，SQL怎么了？SQL就是适合数据操作。（当然，我忽略了SQL的具体实现的不兼容性）。 二、各位对LINQ什么看法？我觉得似乎一下子导致各种ORM失去了阵地。而且确实比较间接直观。当然，TrustNo1曾说过LINQ不过就是Foxpro 语言的换皮，这点确实如此，但是，Linq导致了Lambda Expr，Extend Method，Type Inference等的出现，也算是有点改进，把fp中一些很好的概念拿过来了。 |
| 返回顶楼 | |
|
发表时间：2006-09-21
simbasun 写道 不仅仅是制造话题,是有了新宠(ActiveRecord),忘了旧爱(Hibernate).. 思想随时代在变化，嘿嘿，努力在鸡蛋里面挑骨头！！！
|
| 返回顶楼 | |
|
发表时间：2006-09-21
robbin 写道 对于Hibernate，有两点值得反思：
1、HQL创造出来一种语言，目的是以对象方式类SQL去查询数据库，但是为什么不像rails那样，干脆直接定义COC让数据库schema 和对象的schema吻合在一起呢？这样，SQL不就是直接变成了对象查询语言了吗？缺点就是放弃更多更复杂的对象映射模型。但是我的经验表明，项目中要尽量避免复杂的对象映射，这样性能很糟糕，也很容易出错，实际上我仅仅只用n:1就可以表达很多种映射模型了。化繁为简，大巧若拙实为最高境界。 2、现在极其厌恶Hibernate生成的SQL，又臭又长，极难阅读。 感同身受啊 1， 要坚持简单的对象模型，反对使用复杂对象模型 2， hibernate生成的sql即使format后还是很难阅读 |
| 返回顶楼 | |
|
发表时间：2006-09-21
做报表时，用Hibernate生成一个复杂的SQL语句，真是煞费心思，左连右连痛苦，后面就只能直接用JDBC来实现，用hibernate实现对象add,update,delete是容易，但是，复杂的业务，就没法容易实现了
|
| 返回顶楼 | |
|
发表时间：2006-09-22
复杂的业务请写到存储过程中去，这是最高效的办法。
|
| 返回顶楼 | |
|
发表时间：2006-09-23
Nicholas_Ding 写道 复杂的业务请写到存储过程中去，这是最高效的办法。 写到存储过程中，就和移植性考虑冲突呀。
两难的问题，其实最主要的是要定义问题场景。 在什么场景下用什么东西，实用第一。 |
| 返回顶楼 | |
