hibernate如何处理存储过程中的复杂逻辑

最近有个内部系统要实施给第三方,遇到一个比较大的问题,我们一些关键逻辑都是存储过程(oralce),其他都是hibernate,如果实施给第三方的话,他们打开数据库就直接能看到我们的逻辑代码,因此想把逻辑放在java层,重新封装成service放在容器中以供调用,现问题如下:
如果全部翻译成java(HQL,原生SQL逻辑)工作量太大,性能肯定也不尽理想。所以想问问各位朋友对于这种情况一般处理的方案是什么?hibernate有没有封装大段逻辑原生sql的调用方法?
[该贴被zhoujinliang于2011-10-17 00:05修改过]

2011年10月16日 23:37 "@zhoujinliang"的内容
如果全部翻译成java(HQL,原生SQL逻辑)工作量太大,性能肯定也不尽理想。 ...

逻辑使用存储过程,和逻辑使用Java等应用程序是两种完全不同的系统,就象说中文和说英文一样,翻译过来等于重写。

逻辑全部使用Java等应用程序性能扩展性scalable都会比存储过程好得不只多少倍,鉴于这是两个边界内的世界,所以,不想引起争论,只是说一下。

因为Hiberante是一个ORM框架,也就是将数据库服务于语言对象的框架,不是一个全面的持久层框架,可以认为原声SQL或HQL只是其补充的一个功能,从这个逻辑推导不会有太强支持SQL封装的方式,个人认为你们这个案例属于误用Hibernate的典型案例,有些另类,但很现实,这也反映了Hibernate这些ORM框架的致命问题,本来对象和关系数据库本来无法协调,你要做好人去协调,结果里外不是人。

banq说的非常在理,在下也非常赞同,鉴于目前的实施上线压力,我对我们的系统制定的改造如下:

目前的情况:
1、目前的商业逻辑也是以前的遗留系统留下的,全是存储过程
2、几乎所有的界面我们用hibernate进行了翻写。

改造的思路:
1、想办法利用java包装存储过程,将存储过程先从数据库中拿出来(保护产权,源码)
2、简单的存储过程直接翻写成java逻辑
3、第三方实施
4、后续版本将复杂逻辑全部翻写为java,封装成良好的API接口以供调用。

ps:我们的系统是个ERP。

所以现在我面临的问题就是改造中的第二点,怎么样在兼顾性能和开发时间的情况下,找到把大段大段的sql逻辑从存储过程中搞出来的技术手段,因为我目前发现的jdbc也好,hibernate也好都是单条sql语句执行,如果按照这样翻写那还不如直接翻写成面相对象的java逻辑。

2011年10月17日 10:44 "@zhoujinliang"的内容
怎么样在兼顾性能和开发时间的情况下,找到把大段大段的sql逻辑从存储过程中搞出来的技术手段 ...

提供一个思路:把SQL逻辑以从读写两条线索进行分类,sql读就暂时不要移植,sql写移植出来,SQL写又分为创建写和修改写以及删除写,创建写和删除写移植难道不是很大,先从创建写SQL移植入手。