這個問題不錯啊，之前在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種風格)