作者：Aargan
現在流行很多ORM工具,其中HIBERNATE算做得很好的了,使用的人群也非常多,而且大做都在說好,為什麼讷?使用簡單,開發比較快速,但是問題也隨之而來了....
* 本文假設開發的都是和數據庫相關的項目
ORM能做什麼?幫你用對象的方式來操作RDBMS,這是很多人渴望的,因為他不再需要關心底層數據庫是怎麼工作的了,甚至不需要知道數據庫的結構,一切都交給ORM去管理了,看起來是非常好的,程序非常直觀,寫起來也容易,但是運行起來呢?
事實上,開發者使用ORM工具時,最痛苦的也許就是DBA了,作為DBA,要保證整個系統的性能,必需對一些運行不好的SQL進行TUNING,做一些優化,調整其執行計劃,是整個應用的性能及穩定性提高,但是當他們發現有SQL性能不好,需要找程序員協調修改時,得到的回答是:"我們使用xxx (某ORM工具),SQL都是他生成出來的,我沒辦法調整",ft,你不調整,難道我來啊?最終結果呢,程序跑不動,該改得還是得改,管你用什麼xxx, 這時候也許就會覺得痛苦了吧?
原來ORM並沒那麼好用?SURE,object的世界和relational的世界本來就不能很好的映射,就不要要求他那麼完美了吧!
那要麼我就就用原始的SQL語句,在程序裡直接用JDBC操作,這總不會有什麼限制了吧,是的,你用SQL語句能做的東西你都能做,但是怎麼做讷?
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
log.info("==SQL==:" + sql);
try {
conn = getDataSource().getConnection();
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
return readSingleObjectFromResultSet(rs);
} finally {
close(rs, stmt, conn);
}
ft,大哥,太麻煩了吧,每查這麼一次就要寫這麼多東西啊,我真的只需要執行語句SQL語句而已啊,
是的,你只需要執行易於SQL語句,但是你必需這麼做
不管怎麼,麻煩是麻煩了,但總能工作了吧,返回結果呢?ResultSet,我不覺得他很合適,Connection一關了他就不能用了,要是不關讷,等我用完了再關,(不是吧,那是Connection讷,很金貴的,HINT:對於"貴重"的資源在真正需要時才使用,而且用完了馬上釋放掉,誰讓他那麼寶貴讷),於是,在讀出數據之前,現把結果拿出來,關掉Connection,返回,這裡可以做一些工作,讓你的ResultSet裡取得的數據返回得更漂亮一些,做一些映射,放到一些簡單的bean裡返回給上層使用
相比之下,大多數人都選擇ORM和JDBC結合使用的辦法,簡單的CRUD操作,就讓ORM去做吧,簡單,省心,開發效率高,的確是這樣,其他的工作讷, 不要勉強你的ORM工具,也不要說他不夠完美,事實就是這樣,OBJECT 和 RELATIONAL本來就不是一樣的東西,哪能那麼完美的映射讷?
那我們就這麼用吧,但是問題又來了,你寫在程序裡的SQL,;盡管是少數,但這些都是比較復雜的了(不是麼?),運行了一段時間,DBA又來找了:
那個誰誰誰,你的這個SQL需要搞一下,要加個HINT,調整一下執行計劃,否則數據庫的COST太大了
不是吧?又要改?(怎麼說又?難道不是麼,改的還少了?)
於是就修改,編譯,打包,測試,發布.........DBA又來了....(怕怕)
於是就有了iBATIS,他是一個什麼東西呢?基本上,他有兩部分內容:SQL map 和 DAO.
SQL map是核心的內容,負責將你某一次操作影射到一個SQL語句上去執行,當然,這個SQL語句是可以預見並且非常靈活且容易調整的,DAO是一個上層一點的封裝,目的是為了讓整個應用更加靈活,自由
使用iBATIS最大的誘惑就是,系統運行的所有SQL語句,你都可以在程序以外進行調整,功能上的可以開發者來做,性能上的麼,把你的配置文件給DBA,他會給你做好的,很輕松,不是麼?
