傳智播客JAVA培訓 2010610 Ibatis學習筆記
今天是非常激動的一天，也是非常幸運的一天吧！今天面試了兩家公司，居然今天下午這一家公司決定叫兩天後去公司報到！嘿嘿！試用期3.5K，轉正後另定！雖然或許有些人感覺我的追求太低了，但是我很認真的告訴你：我感覺還行！至少現在我不在擔心我不能在這個行業裏呆下，我有了一個立足之本，所以以後是誰都無法預料的。如果沒有衣食的保證，用什麼去繼續深入的學習呢？
這幾天的面試，每走一個公司，對我的打擊和激勵是非常大的，我是真的發現基礎對於面試是起着非常重要的作用！爲什麼這麼多的公司考試的題都是非常基礎的呢？說實在的我，如果換成以前的我真的有點想不通！只不過，開發也有這麼久的時間了，如果還是想不通的話，我在成均的這段時間也算是白混了吧！其這一兩年努力也就沒有任務意義了吧！軟件之門深如海啊！只有當你進入這個門檻了，纔會對此有一定的感觸吧！萬丈高樓從地起，所有的所有的一切的基石，JAVA軟件工程師的基石：JAVA編程思想！但這些思想是建立在你掌握和她的基礎之上的！
因爲公司要用到的是ibatis這個框架，雖然還沒有正式的去報到，但我也得提前準備，正所謂，咱們不打無準備的仗。所以提前學習，對於我，對於工作都是非常有幫助的呵！實用期這兩個月，咋得好好的幹，爭取早日修得正果！
當然這個和學習JAVA其它框架一樣，都得導入jar包，和數據庫的jar包。
配置文件：
HIBERNATE 和 IBATIS 的比較：
ibatis:sql需要自己寫
hibernate:sql自動生成
對於IBATIES和HIBERNATE的細節，我想只有對這兩個框架都非常精通之人，才能說出其中的真諦吧！我在這兒不敢造次，我引用別人寫過的，作爲一個參考：
對於實際的開發進行的比較：
1． iBATIS需要手寫sql語句，也可以生成一部分，Hibernate則基本上可以自動生成，偶爾會寫一些Hql。同樣的需求,iBATIS的工作量比 Hibernate要大很多。類似的，如果涉及到數據庫字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。
2. iBatis 可以進行細粒度的優化
比如說我有一個表，這個表有幾個或者幾十個字段，我需要更新其中的一個字段，iBatis 很簡單，執行一個sql UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用 Hibernate 的話就比較麻煩了,缺省的情況下 hibernate 會更新所有字段。 當然我記得 hibernate 有一個選項可以控制只保存修改過的字段，但是我不太確定這個功能的負面效果。
例如：我需要列出一個表的部分內容，用 iBatis 的時候，這裏面的好處是可以少從數據庫讀很多數據，節省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...一般情況下Hibernate 會把所有的字段都選出來。比如說有一個上面表有8個字段，其中有一兩個比較大的字段，varchar(255)/text。上面的場景中我爲什麼要把他們也選出來呢？用hibernate 的話，你又不能把這兩個不需要的字段設置爲lazy load，因爲還有很多地方需要一次把整個 domain object 加載出來。這個時候就能顯現出ibatis 的好處了。如果我需要更新一條記錄（一個對象），如果使用 hibernate，需要現把對象 select 出來，然後再做 update。這對數據庫來說就是兩條sql。而iBatis只需要一條update的sql就可以了。減少一次與數據庫的交互，對於性能的提升是非常重要。
3. 開發方面：
開發效率上，我覺得兩者應該差不多。可維護性方面，我覺得 iBatis 更好一些。因爲 iBatis 的 sql 都保存到單獨的文件中。而 Hibernate 在有些情況下可能會在 java 代碼中保sql/hql。相對Hibernate“O/R”而言，iBATIS 是一種“Sql Mapping”的ORM實現。 而iBATIS 的着力點，則在於POJO 與SQL之間的映射關係。也就是說，iBATIS並不會爲程序員在運行期自動生成SQL 執行。具體的SQL 需要程序員編寫，然後通過映射配置文件，將SQL所需的參數，以及返回的結果字段映射到指定POJO。使用iBATIS 提供的ORM機制，對業務邏輯實現人員而言，面對的是純粹的Java對象，這一層與通過Hibernate 實現ORM 而言基本一致，而對於具體的數據操作，Hibernate會自動生成SQL 語句，而iBATIS 則要求開發者編寫具體的SQL 語句。相對Hibernate而言，iBATIS 以SQL開發的工作量和數據庫移植性上的讓步，爲系統設計提供了更大的自由空間。
4. 運行效率
在不考慮 cache 的情況下，iBatis 應該會比hibernate 快一些或者很多。
選擇Hibernate還是iBATIS都有它的道理：
Hibernate的特點：
Hibernate功能強大，數據庫無關性好，O/R映射能力強，如果你對Hibernate相當精通，而且對Hibernate進行了適當的封裝，那麼你的項目整個持久層代碼會相當簡單，需要寫的代碼很少，開發速度很快，非常爽。以數據庫字段一一對應映射得到的PO和Hibernte這種對象化映射得到的PO是截然不同的，本質區別在於這種PO是扁平化的，不像Hibernate映射的PO是可以表達立體的對象繼承，聚合等等關係的，這將會直接影響到你的整個軟件系統的設計思路。Hibernate對數據庫結構提供了較爲完整的封裝，Hibernate的O/R Mapping實現了POJO 和數據庫表之間的映射，以及SQL 的自動生成和執行。程序員往往只需定義好了POJO 到數據庫表的映射關係，即可通過Hibernate 提供的方法完成持久層操作。程序員甚至不需要對SQL 的熟練掌握， Hibernate/OJB 會根據制定的存儲邏輯，自動生成對應的SQL 並調用JDBC 接口加以執行。Hibernate的缺點就是學習門檻不低，要精通門檻更高，而且怎麼設計O/R映射，在性能和對象模型之間如何權衡取得平衡，以及怎樣用好Hibernate方面需要你的經驗和能力都很強纔行，但是Hibernate現在已經是主流O/R Mapping框架，從文檔的豐富性，產品的完善性，版本的開發速度都要強於iBATIS。
iBATIS的特點：
iBATIS入門簡單，即學即用，提供了數據庫查詢的自動對象綁定功能，而且延續了很好的SQL使用經驗，對於沒有那麼高的對象模型要求的項目來說，相當完美。iBATIS的缺點就是框架還是比較簡陋，功能尚有缺失，雖然簡化了數據綁定代碼，但是整個底層數據庫查詢實際還是要自己寫的，工作量也比較大，而且不太容易適應快速數據庫修改。當系統屬於二次開發,無法對數據庫結構做到控制和修改,那iBATIS的靈活性將比Hibernate更適合。系統數據處理量巨大，性能要求極爲苛刻，這往往意味着我們必須通過經過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。在這種情況下iBATIS會有更好的可控性和表現。
我明天要去面試，並不是我對現在找到這一份工作不滿意，是因爲我今天答應了我明天一定會去，我也不知道今天這家公司，居然這麼快就定下了我，所以，我必須得去！這算不算一種諾言呢？如果不去的話，雖然對我不能造成什麼直接的影響，但是在我的內心深處，卻告訴我，應該去吧！不然，感覺總有點怪怪的不對！做人，誠信第一！