这个问题不错啊，之前在java iteye也有看到类似的问题
是在讨论hibernate与mybatis混用问题，不过现在找不到文章
大概的内容是一开始大家都觉得不要混用
不过随着讨论串，越来越多人提出实务上的困难，
并说出他们系统其实是混用，例如hibatenate配spring jdbc,或是hibernate配mybatis
结论就是混用是最弹性的。
可以先思考一下ORM 跟 Raw SQL的好处
ORM可以让开发人员减少程式码，方便好用，可解决大部分的基本查询。
只是在多张table串联与复杂查询的时候
性能不好。
Raw SQL需要多写很多程式码，但是适合用在那个复杂查询的情境。
看起来这两个就是再解决不同问题，当然就是混用啊!!
以Java为例(我也只会这个)
ORM : hibernate
Raw SQL : JDBC,Spring JDBC Template,mybatis....
hibernate可以实做公用的程式，
用白话一点说就是所有table的新增、修改、删除、用primary key查询方法
都可以靠着继承公用程式做完。
然后一些基本的查询方法，也是使用hibernate实作
写好hibernate SQL(hql)后，hibernate 就会自动帮忙mapping到物件上
光是这些就可以增加不少开发效率了,也就是开发人员可以少很多程式码
但是要是碰到要做多表查询，例如报表时，如果hibernate可以搞定，
那也可以用hiernate，但是要是碰到性能问题，hibernate SQL(hql)兜不出来
再换成raw sql的方式解决问题。
所以我认为最好的方法，就是这两种方式混用
以hibernate(orm)为主，raw sql为副，
这样两种方法的优点才可以同时享受到。
※ 引述《MacPerson (Gary)》之铭言：
: 最近在开发新的专案，与同事在讨论ORM的相关问题。
: 之前以MVC架构在开发网页时，Model的部分还是用ado .NET，但利用Reflection
: 的方式，将他映射回类别，所以即使用ado来开发，但模型验证的部分，还是可以
: 继续使用。
: 之前会绕过ORM以ADO开发的原因是，团队成员对SQL熟到炸了，不想为了取得资料，
: 来去学习ORM(学习也是成本)，另外ORM也有它的极限，需要用到一堆join跟SQL函数
: 时，真的不知道该怎么把他转为ORM的写法...
: 最近的案子，突然决定Model部分全部改为ORM的方式做处理，但是一遇到棘手的复杂查询
: ，又非得回到ado的方式来做处理。
: 想请问大家在工作上，ado的使用者多还是ORM的使用者多?
: 对于复杂查询时，又必须以ado的方式来解，或者将他包成stored procedure或view，
: 再用ORM去excute，这样感觉像是再走回头路，明明要去SQL化(物件导向)，但一遇到复
: 杂查询却又非得回到ado的方式，Programmer必须得会SQL跟ORM，在程式里出现2种风
: 格的model，其实我还蛮无法接受的....
: 以上跟各位分享与讨论.....
: (此篇非抱怨文，我已经习惯ORM的作业方式，但无法说服自己，必须在model写成2种风格)