|
精华帖 (0) :: 良好帖 (3) :: 新手帖 (19) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-09-24
禁用hibernate查询，不用这么绝对吧。如果太复杂了自然还是写sql的直接
|
| 返回顶楼 | |
|
发表时间：2008-09-24
把hibernate用得更不像样子的人飘过。。。
不过个人觉得，能逮住老鼠，抓老鼠的成本和难度控制好就行。。。。 框架是解决问题的，但是现在太多为了框架而框架，也许俺水平太低了，勿见怪 |
| 返回顶楼 | |
|
发表时间：2008-09-24
纠正楼主一下，原文作者不是我，是网友movingboy。
http://www.iteye.com/post/665448 不过我在文中有回复是真的。 icewubin 写道 那是你们公司特定的环境下的规定，像我们公司的产品必须要跨数据库，就肯定不能用named sql。 很多情况下，为了避免重复需要动态拼sql（hql），这部分的逻辑总得有个地方要放，我不认为放在配置文件中是个好主意，比如iBatis中的判断逻辑判断语法，配置文件和代码文件应该同等对待，都是代码，IDE对配置文件的感知能力是远不如代码文件的。 Java代码根据规范，组织好分层和代码的规范，一样可以分离开发，提高易读性和改进维护难度。 相反，配置文件的规模（行数和文件数和配置文件中的逻辑判断）达到一定程度一样是问题，本质上来讲这个复杂度是不可避免的，你总得找个地方放这些逻辑，不管是在代码、配置文件、存储过程，都一样的。 icewubin 写道 过于复杂的查询本来就不应该用同样的框架去做。
1.首先从商务上，我们公司会把这方面的需求转到BI上来做，数据仓库部门和数据挖掘部门是我们公司比较强的地方。 2.如果复杂度没有到BI这一层面的话，或者说必须要用Java来做的话，统计报表本来就应该单独设计，至于这部分的实现是不是用Hql还是本地sql可以另讨论，但是不要把统计报表类的需求延展到其他事务操作型的需求上。 3.我们的产品正好没有什么统计报表的需求，我也建议统计报表类的需求实现单独讨论比较好。 1.楼主就是一个电信的统计报表类项目，没必要说成是“电信级”项目吧。 2.Hibernate使用是需要相关配套设施的，比如如何把很多多表查询转换成单表查询，牵涉到整个框架的设计和支撑。 3.制定规范的时候，不知道楼主自己是不是经常参与开发实践，我虽然制定公司架构，但是自己一直是在一线和程序员们一起参与的（不会过多参与，不然瓶颈就在我身上了），要多了解使用框架和规范的程序员们的想法。 4.从楼主举的例子来看，好像数据库设计的不是特别好，因为资料不多，我也不好多说，但是那个子查询的例子，建议用exists实现。 5.hibernate本质上来说就是个高级的sql生成器+各种辅助设施。在设计系统的时候，大脑中浮现出来的当然是只有sql了，核心问题就是如何管好这些sql，不管是存储过程、ibatis、hibernate都是sql的拼装、构造的过程，然后就是评估拼装、构造的逻辑代码放在哪里更好的决策，仅此而已，不需要上纲上线。 6.很多人说jdbcTemplate好，我也经常用，是很好用，不过最好也看看它的整体结构，用的不好也会出性能问题。 |
| 返回顶楼 | |
|
发表时间：2008-09-24
发挥每个框架的优点，避免使用其缺点哈！
比如：hibernate+jdbc+ibatis+存贮过程 哈，因为程序员的水准不一样，架构师可能就要辛苦一点了 呵呵！ |
| 返回顶楼 | |
|
发表时间：2008-09-25
hibernate都用不好，还说个P呀
|
| 返回顶楼 | |
|
发表时间：2008-09-25
zlst 写道 hibernate都用不好，还说个P呀
我经常听别人说hibernate很简单，但这样的人10个有9个不行，莫非你是这唯一的例外？ |
| 返回顶楼 | |
|
发表时间：2008-09-25
我觉得楼主是在真正分析问题，后面回复的有很多只是简单地唱反调，因为他们拥护Hibernate~~！
我同意楼主在这样特定的需求条件下做出的Hibernate规范决策，当然，我也建议楼主可以转型使用iBatis，你的需求用iBatis会比Hibernate更适合。 现在Hibernate新版本中增加了些对SQL的自由定制支持，说明G.K还是知道这些问题的。如果Hibernate的NamingSQL能支持像iBatis那样的动态条件拼装那就OK了，只是目前没有这种功能。 另外，许多人说这是OO思想还是关系思想的对立问题，我到不这么认为，从性能角度上讲，两个层面都需要做优化，并且需要从架构层面考量的，并不是简单的一、两级Cache就万事大吉了。 如果是我，在面对这种动态条件拼装频繁的项目前提下，我也会选择使用iBatis，除非Hibernate下一个版本增加了动态拼装的功能。 当然，话又说回来，万事都不是绝对的，如果从纯性能的角度上来看，有些多表关联查询有可能只仅仅是简单的动态拼装也未必适用，因为不同的条件其优化后的SQL语句是不同的，需要走不同的执行路径，这个数据库密切相关。 有许多人认为用Hibernate就可以不用理解SQL了，我不认为是这样的，Hibernate只是一个工具，代替不了SQL,开发人员本身就应该编写SQL的责任，只不过不需要太过深入，高级的、棘手的优化工作DBA可以帮助你完成。 最后，我现在就是Hibernate+iBatis整合起来在用，如果再启一个全新的项目，在Hibernate没有对动态拼支持以前，我还会选择iBatis. 就事论事，大家可别攻击我。。。 |
| 返回顶楼 | |
|
发表时间：2008-09-25
我们就使Hibernate和Spring的JdbcTemplate混用的，没看出iBatis比JdbcTemplate强。在配置文件中进行动态拼sql本身就是比较搞笑的一件事。
|
| 返回顶楼 | |
|
发表时间：2008-09-26
langds 写道 我觉得楼主是在真正分析问题，后面回复的有很多只是简单地唱反调，因为他们拥护Hibernate~~！
我同意楼主在这样特定的需求条件下做出的Hibernate规范决策，当然，我也建议楼主可以转型使用iBatis，你的需求用iBatis会比Hibernate更适合。 现在Hibernate新版本中增加了些对SQL的自由定制支持，说明G.K还是知道这些问题的。如果Hibernate的NamingSQL能支持像iBatis那样的动态条件拼装那就OK了，只是目前没有这种功能。 另外，许多人说这是OO思想还是关系思想的对立问题，我到不这么认为，从性能角度上讲，两个层面都需要做优化，并且需要从架构层面考量的，并不是简单的一、两级Cache就万事大吉了。 如果是我，在面对这种动态条件拼装频繁的项目前提下，我也会选择使用iBatis，除非Hibernate下一个版本增加了动态拼装的功能。 当然，话又说回来，万事都不是绝对的，如果从纯性能的角度上来看，有些多表关联查询有可能只仅仅是简单的动态拼装也未必适用，因为不同的条件其优化后的SQL语句是不同的，需要走不同的执行路径，这个数据库密切相关。 有许多人认为用Hibernate就可以不用理解SQL了，我不认为是这样的，Hibernate只是一个工具，代替不了SQL,开发人员本身就应该编写SQL的责任，只不过不需要太过深入，高级的、棘手的优化工作DBA可以帮助你完成。 最后，我现在就是Hibernate+iBatis整合起来在用，如果再启一个全新的项目，在Hibernate没有对动态拼支持以前，我还会选择iBatis. 作为架构小组的一员，可不是选好 framework，把官方文档给 程序员 就完事了。 就事论事，大家可别攻击我。。。 哈哈，终于找到知音了。 
实际上我在公司的JavaEE 框架中已经完善的封装了动态拼装附加条件 SQL 的功能，并且用法比 Hibernate， ibatis 本身更为简单，算是一个增强扩展包。 只是本文是该主题的第一部分， 提出了问题， 下篇会详细介绍这一增强扩展的用法和实现原理。最近比较忙，一直没时间整理。 
难得碰到以解决问题为道的知音，再次 一下。以后多交流。
|
| 返回顶楼 | |
|
发表时间：2008-09-26
最后的结论就是 禁用 Hibernate
|
| 返回顶楼 | |
