現有一些ORM工具的弊端

2019-11-18 11:55:09

字體：大中小

來源：轉載

供稿：網友

　　作者：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,他會給你做好的,很輕松,不是么?

上一篇：Java實用工具

下一篇：JProfiler跟蹤和檢查系統性能的好工具