Ibatis的優缺點及可行性分析

關鍵字: ibatis的優缺點及可行性分析

1.優點

簡單：

易于學習，易于使用，通過文檔和源代碼，可以比較完全的掌握它的設計思路和實作。

實用：

提供了資料映射功能，提供了對底層資料通路的封裝（例如ado.net），提供了DAO架構，可以使我們更容易的開發和配置我們的DAL層。靈活：

通過sql基本上可以實作我們不使用資料通路架構可以實作的所有功能，或許更多。功能完整：

提供了連接配接管理，緩存支援，線程支援，（分布式）事物管理，通過配置作關系對象映射等資料通路層需要解決的問題。提供了DAO支援，并在DAO架構中封裝了ADO.NET，NHibernate和DataMapper。增強系統的可維護性：

通過提供DAL層，将業務邏輯和資料通路邏輯分離，使系統的設計更清晰，更易維護，更易單元測試。sql和代碼的分離，提高了可維護性。

2.缺點

滞後性：

還沒有明确對.NET2.0的支援。最新版本在2.0下編譯可以，但有些單元測試不能通過。

不成熟，工程實踐較少：

IbatisNet在實際項目中的使用較少。 隻是理論上可行.

半ORM，工具支援較少：

需要我們自己寫sql，并且.NET下還未發現可以自動生成業務層類和配置檔案的工具，這點和NHibernate不一樣，NHibernate會為我們的資料庫直接産生sql，并有一些輔助工具。是以使用Ibatis比NHibernate要多做一些工作。

3.可行性

    沒有最好的架構，隻有最适合的架構。 存在的便是合理的，它存在就說明有它存在的道理。但它未必為我們存在。是以選擇一個架構最主要的是看它對你有沒有意義，意義有多大，是不是比其他架構帶給你的好處要多。沒有絕對的優點也沒有絕對的缺點，重要的是看在什麼情況下讨論。    上面說了部分的Ibatis的優點和部分缺點。這些優點從理論上證明Ibatis對任何資料持久層都合适，但未必是最好的選擇。下面對上面的優缺點分别從兩方面讨論。簡單：    我們都喜歡簡單，簡單意味着學習成本低，使用中出錯的可能性低。同時，簡單的東西一般來說功能不夠強大。反過來，複雜的東西學習成本高，用起來不友善，并且團隊沒有很強的技術實力，一般不要使用。實用：

    解決了項目中需要解決的問題，這是任何實際工程中采用的架構和工具都應具有的性質，否則就不要拿到實際項目中來。靈活：    靈活有兩層意思，一種是簡單易擴充，另一種是功能強大提供了很多選項。Ibatis屬于前者，Hibernate屬于後者。兩者各有優缺點。功能完整：    Ibatis的功能完整也是相對的，比我們自己開發的架構應該完整，但對比其他架構肯定也有一些解決不了的問題。增強系統的可維護性：    利用Ibatis可以做到sql和代碼分離，可以設計出一個清晰的資料通路層（DAL）。但項目架構是否科學合理，是否以維護，關鍵不在Ibatis，因為它隻是一個資料層架構。但是我們也不得不清楚，要想發揮Ibatis的優勢，我們需要做一些額外工作，比如最好設計DAO接口，需要将業務層實體和對實體的通路放在不同的工程中，同時需要維護xml配置檔案。滞後性：    Ibatis組現在還沒有提到要支援.NET2.0，很多人在.NET2.0下使用Ibatis都出現了問題。是以如果要使用.NET2.0開發，IBatis不是一個好選擇，還需要等待。不成熟：    開源的東西很難說成熟，但一般比我們自己寫的架構要成熟。由于我們可以拿到他的源代碼，是以關鍵在于我們能否駕馭它。半ORM，工具支援少：    這注定了Ibatis不能從本質上提升開發效率，我們需要自己寫sql，寫實體類，寫配置檔案。但這也是它優越的地方，它沒有為我們做的他多，是以我們就有更多的施展空間。而且它非常适合那些并不能完全控制資料庫的系統和需要利用資料庫本身提供的進階特性的統計查詢系統的開發。

    使用Ibatis需要自己寫sql，由于我們的sql不可能完全符合sql标準，比起NHibernate産生的sql來，可移植性差。不過由于我們更改資料庫的可能性較小，對我們來說sql符合标準以便可以在遷移到不同伺服器時代價最小并不是十分必要的。另一方面，NHibernate雖然可以屏蔽很多資料庫間的不同，但是卻很難利用某些資料庫的進階特性，比如Oracle的分析統計函數。

     NHibernate不适合資料庫模式不規範，限制不完整，需要大量複雜查詢的系統，同時NHibernate的學習成本較高，完全掌握NHibernate也較困難，風險較大。    自己寫架構未必比Ibatis的好，穩定，強大和可擴充。而且自己開發架構也需要較大的工作量。    如果使用DotNet并且要選一個資料層架構，而系統中有相當一部分較複雜的sql，或資料庫設計不合理，髒資料多，對性能和資源要求嚴格，Ibatis是一個比較不錯的選擇。他的那些缺點并不是緻命的，而且也是有一些解決方案的。尤其是，當選用了Ibatis的DataAccess作為DAO架構時，我們可以同時使用NHibernate，ADO.NET和DataMapper（IbatisNet的核心元件），那樣将會使風險降到最低，并且整個系統的架構比較合理。

另外，利用Ibatis可以統一編碼風格，節約開發成本，大家不會再把精力浪費到分頁  連接配接池 主鍵生成等地方了,可以集中精力進行業務元件的編寫。 

綜上:   

     很多時候我們要在是自己開發架構和選用第三方架構和選用什麼樣的架構問題上進行綜合考慮。考慮的标準當然是項目的目前情況和我們希望達到目的的一個平衡。

     Ibatis隻是封裝了資料通路層，替我們做了部分的對象關系映射。但我們的代價是必須要寫xml配置檔案，相對于Hibernate我們還要寫很多sql。Hibernate通過工具直接從資料庫模式生成實體類和基本的配置檔案，而且大部分情況下不需要我們寫sql，會較大的提升開發效率。但這些也有很多的局限性，尤其是對環境的要求較高（資料庫設計，對象設計，團隊的協作等）。    個人感覺Ibatis對項目比較有意義的地方在于它小巧靈活，可擴充，封裝了資料通路層（事務，緩存，異常，日志），并提供了DAO架構支援。

    利用Ibatis我們可以做到代碼和sql的分離，隻要sql能夠解決的問題，Ibatis就能幫我們較容易的解決，同時也使我們的項目對某一架構的依賴性變小（因為Ibatis是非侵入性的）。這将極大的降低項目風險，減少解決複雜問題的時間，使項目的維護變得簡單。

   Ibatis對于應用的修改，調試，擴充和維護将會變得容易自然。修改時，我們主要修改的是代表模型的實體對象，xml配置檔案中的sql，和/或配置檔案的ResultMap（很多時候是不需要的）。同時，sql和代碼分離，我們不用在代碼的StringBuffer的append方法之間尋找需要修改的sql。配置檔案中的sql便利了我們的調試和對sql的評審及以後的sql重用。

    利用一些架構在前期一般會拖慢開發效率。因為我們需要付出學習成本，很多時候，使用架構需要寫很多配置檔案，在使用不熟時開發速度較慢；同時利用架構往往使系統代碼量增大，比如Model1和Model2模型，開發效率應該還是Model1快，四層的架構肯定比兩層的代碼量大。 但對于中後期開發和維護将會極大的提高效率。

    利用一些較完全的開發架構和代碼生成工具，在前期會較大的提高開發效率，但在後期常常會拖慢進度，并有可能成為以後維護的夢魇。比如torque生成實體類和其對應的sql，雖大幅提高了效率，但修改負擔較大。

   比較理想的開發方式是使用簡單架構結合簡單的代碼生成工具。架構提供系統的基礎服務，并規範開發。架構一方面提供了開發中某一方面的開發基礎支援，比如資料通路層，事務，日志，公用類，異常等。另一方面，也為開發定義了模式，定義了系統的基本輪廓。同時，通過簡單的代碼生成工具生成部分低級的代碼。比如通過工具從資料庫模式生成實體類。這些類生成後我們可以自由修改。

    Hibernate是十分強大，比較完善的ORM架構，不過這是它的優點也是它的缺點。 j2ee系統是否采用Hibernate3，是一個需要認真評估的問題。

    要想Hibernate工作的好，資料庫的設計必須好。同時對于複雜的資料操作同時需要使用sql，Hibernate3對于直接使用sql的支援比Hibernate2要自然，這一點是可以接受的。

    Hibernate比較複雜，功能強大而靈活，要用好Hibernate确實不是很簡單，當然Spring架構提供了對Hibernate的封裝，使Hibernate的使用變得簡單了點。    可以說Ibatis在任何系統裡都适用，但未必是最好選擇。不過Ibatis提供的思路是我們應該仔細考慮的。

轉載。。。

内容比較客觀且實際的比較了IBatis和Hibernate的優缺點，對于兩者架構的選擇确實是值得思考的問題，本人持學習的态度，對兩者充滿期待。。。