我的开发规范分享(二)- 禁用Hibernate HQL,QBC,QBE编程(1)

其实就是禁用hibernate，还这么复杂搞个禁用HQL。像生成报表之类的复杂查询，我想JDBC都不适用。

named sql query 本身也是 Hibernate 的一个的特性。

看了你的帖子，我有点莫名的郁闷，你都做到了架构设计了，难道还不了解hibernate和原生sql的关系吗？
他们解决问题的方式是不同的：
hibernate:一方面是让你用OO的思想去思考问题 ；另一个方面是说我不是为了优化sql，而是采用缓存，提高命中率，减少DB的访问
而SQL，不一样，它是面向DB的，优化SQL等方式提高DB的性能，这个是他的职责。
从这个文章来看，电信真是烂

   同意你，我在公司项目中制定这个开发规范正符合 ibatis 的特点。

   因为 2006年项目启动时，已经确定使用 Hibernate 3， 而公司以前编程规范是使用 HQL, QBC 的 ， 正好那次在项目初期对Hibernate 这一使用规范逐渐纠正过来。

如果是新的项目， 我想我会选 ibatis 的。

  话不要说这么绝对。Named SQL Query本身也是Hibernate 的一个特性，千万不要将它和  Hibernate 对立起来。 （这是我 2006 年确定的 Hibernate 使用的规范。）

  如果你面对的是新项目，你这样说完全 OK。
  如果是一个 2006年 已经确定用 Hibernate 的项目， 在项目初期遇到复杂查询业务，不知你会怎样处理开发和选型的问题？　

  在理论 hibernate 和 sql 有你所说的区别； 但在实际项目中， 你可以看看情况是怎样的；你只看到 sql 面向DB，而没注意业务的复杂性； 我不相信你只用 Hibernate 的 OO 在一个项目里就能搞定所有业务需求。

   还是感觉很多朋友只是教条的坚持每个技术的标准特点和规范，不能做适当变通。

   本文分享出来，正是给使用 Hibernate 的兄弟提供一个实践经验的参考。

面对复杂的查询，或者说关联的表稍微多一点，hql生成的sql就会有半个屏幕,确实感觉不是很舒服啊

对，我们系统现在使用的100多个报表，现在都用存储过程做。一方面是业务规则比较复杂，一方面是考虑复杂的sql在效率方面会有问题，而且难以优化。

我恰恰相反，我认为使用hibernate要尽量使用HQL。
对于复杂查询我们引入jdbctemplate就可以了。

最佳实践有多种，Store Procedure 也是一种我们以前使用过的方式，而且Hibernate 对此也是支持的。如果能充分结合 Hibernate Cache功能，这也是一个不错的方案，只要你们定下一个规范就可以了。

我认为电信级别的项目不适合用hibernate,新手用好hibernate可不是件容易的事,一个项中开发规范和技术架构很很重要.