当遇到处理复杂业务逻辑的情况，使用了hibernate，你是怎么处理的？

当hibernate遇到了复杂业务的情况，不能像ibatis那么随意的定义sql再mapping xml文件里(hibernate其实也是可以的，如下：

<sql-query name="getComponentQuery">
<return alias="com" class="com.vizia.app.bo.ViewGetcomponentaclBymoduleid"/>
<![CDATA[

select main.id as {com.id},
main.code as {com.code},
main.description as {com.description},
main.component_type as {com.componentType},
main.module_id as {com.moduleId},
b.mask as {com.mask}
from (SELECT a.id,
a.code,
a.description, a.component_type, a.module_id
FROM tb_component a where a.module_id =:moduleId)main
LEFT JOIN tb_component_acl b ON main.id = b.component_id
]]>
</sql-query>

)

但是你要事先定义好一个一个BO（或者叫VO，在hibernate看来，一个bo还需要一个mapping xml），在mapping文件里还得指定当前mapping的table，但是写复杂SQL，常常需要join 多张表，如何指定呢？

由此引出来一共有四种解决方案：

1.是写一个视图（view），然后generate一个对应的BO和mapping xml。这样的好处，容易维护，当做数据库方面的迁移的时候，修改的只有view的schema。但是这样为了一次复杂查询就得多出来两个文件（一个bo class一个mapping xml）。

2.就像上面说的，在mapping xml里定义一个sql-query，这样弊端就是常常要多张表，配置mapping文件比较麻烦。但是维护性比写在view里要差一些。当做数据库迁移的时候，需要改动xml文件。

3.第三种是我目前个人认为是最高效率的一种方案，就是在你的DAO里写Native SQL－－注意不是hql，做过程序员的都知道，写比较纯正的sql可以解决很多复杂业务的查询。而hql却有很多限制－－－至少在hibernate3.0还是不那么随意自由的。比如：这样的不算复杂的sql想转换成hql就比较困难：

select main.*,c.* from (select a.* from est_step_sub_cost a,
est_job_section b where b.job_section_id =a.section_id and b.header_id=？)main
left join est_step_cost c on c.step_cost_id =main.step_cost_id;

最后没有办法，我选择了hibernate里的Native sql－－其实这也不是纯正的sql，个人理解是一种介于sql 和hql之间的一种，如下：

StringBuffer hql =new StringBuffer(" select {main.*},{c.*} from (select a.* from est_step_sub_cost a, est_job_section b where b.header_id = ").append(headerId);
hql.append("and b.job_section_id =a.section_id)main left outer join est_step_cost c on c.step_cost_id =main.step_cost_id");
Query query = getSession().createSQLQuery(hql.toString()).addEntity("main",EstStepSubCost.class).addEntity("c",EstStepCost.class);
List list =query.list();
return list;

评价：这样的弊端是可能跟数据库平台依赖性比较大，在以后做数据库迁移的时候比较麻烦，我们采取的做法，确保自己的代码不要出现跟平台藕荷的sql，比如很多function或者Date方面的处理；好处就不用多说了。

但是使用这种方法的时候，需要注意，返回的这个list的存放的Object是一个Array，所以你需要自己处理，比如说当需要在页面显示的时候。

4.最后一种写hql，这种hql我个人认为在简单业务的处理，还能勉强凑合。复杂的还是，hql还是不够灵活。

而且执行的效率performance是几种当中最差的。

欢迎讨论。。。。