Re: [討論] ORM or Raw SQL

[achaos (熱~~~~)]

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

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 59.115.91.172
※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1407082138.A.854.html
※ 編輯: achaos (59.115.91.172), 08/04/2014 00:11:14
推 derekhsu:用Mybatis+Hibernate，你就不用在程式裡面寫SQL
→ Lordaeron:又要學hibernate又要HQL,還要去搞SQL, 哪何苦呢.
→ Lordaeron:單一SQL 搞定的事, 要變這麼多.
→ achaos:那可以說一下你們動態條件查詢怎麼做嗎？ 例如mybatis的 if
→ achaos: 功能。
推 iceonly:個人看code比看SQL快多了，雖然說把邏輯寫進SP是快很多沒
→ iceonly:錯啦...
推 pennymarkfox:我以為mybatis沒人在維護了=_=