⑴ 什麼是mybatis框架
MyBatis 本是apache的一個開源項目iBatis, 是一個優秀的持久層框架。它對jdbc的操作資料庫的過程進行封裝，使開發者只需要關注 sql 本身，而不需要花費精力去處理例如注冊驅動、創建connection、創建statement、手動設置參數、結果集檢索等jdbc繁雜的過程代碼。Mybatis通過xml或註解的方式將要執行的各種statement（statement、preparedStatemnt）配置起來，並通過java對象和statement中的sql進行映射生成最終執行的sql語句，最後由mybatis框架執行sql並將結果映射成java對象並返回。
⑵ mybatis工作原理及為什麼要用
一、mybatis的工作原理：
MyBatis 是支持普通 SQL查詢，存儲過程和高級映射的優秀持久層框架。MyBatis 消除了幾乎所有的JDBC代碼和參數的手工設置以及結果集的檢索。
MyBatis使用簡單的 XML或註解用於配置和原始映射，將介面和 Java 的POJOs（Plain Ordinary Java Objects，普通的 Java對象）映射成資料庫中的記錄。
每個MyBatis應用程序主要都是使用SqlSessionFactory實例的，一個SqlSessionFactory實例可以通過SqlSessionFactoryBuilder獲得。用xml文件構建SqlSessionFactory實例是非常簡單的事情。
推薦在這個配置中使用類路徑資源，但可以使用任何Reader實例，包括用文件路徑或file://開頭的url創建的實例。MyBatis有一個實用類----Resources，它有很多方法，可以方便地從類路徑及其它位置載入資源。
二、使用mybatis的原因：因為mybatis具有許多的優點，具體如下：
1、簡單易學：本身就很小且簡單。沒有任何第三方依賴，最簡單安裝只要兩個jar文件+配置幾個sql映射文件易於學習，易於使用，通過文檔和源代碼，可以比較完全的掌握它的設計思路和實現。
2、靈活：mybatis不會對應用程序或者資料庫的現有設計強加任何影響。 sql寫在xml里，便於統一管理和優化。通過sql語句可以滿足操作資料庫的所有需求。
3、解除sql與程序代碼的耦合：通過提供DAO層，將業務邏輯和數據訪問邏輯分離，使系統的設計更清晰，更易維護，更易單元測試。sql和代碼的分離，提高了可維護性。
4、提供映射標簽，支持對象與資料庫的orm欄位關系映射。
5、提供對象關系映射標簽，支持對象關系組建維護。
6、提供xml標簽，支持編寫動態sql。
(2)持久層動態sql擴展閱讀：
mybatis的功能構架：
1、API介面層：提供給外部使用的介面API，開發人員通過這些本地API來操縱資料庫。介面層一接收到調用請求就會調用數據處理層來完成具體的數據處理。
2、數據處理層：負責具體的SQL查找、SQL解析、SQL執行和執行結果映射處理等。它主要的目的是根據調用的請求完成一次資料庫操作。
3、基礎支撐層：負責最基礎的功能支撐，包括連接管理、事務管理、配置載入和緩存處理，這些都是共用的東西，將他們抽取出來作為最基礎的組件。為上層的數據處理層提供最基礎的支撐。
⑶ 有比 mybitis 更好的框架嗎
有 hibernate
第一方面：開發速度的對比
就開發速度而言，Hibernate的真正掌握要比Mybatis來得難些。Mybatis框架相對簡單很容易上手，但也相對簡陋些。個人覺得要用好Mybatis還是首先要先理解好Hibernate。
比起兩者的開發速度，不僅僅要考慮到兩者的特性及性能，更要根據項目需求去考慮究竟哪一個更適合項目開發，比如：一個項目中用到的復雜查詢基本沒有，就是簡單的增刪改查，這樣選擇hibernate效率就很快了，因為基本的sql語句已經被封裝好了，根本不需要你去寫sql語句，這就節省了大量的時間，但是對於一個大型項目，復雜語句較多，這樣再去選擇hibernate就不是一個太好的選擇，選擇mybatis就會加快許多，而且語句的管理也比較方便。
第二方面：開發工作量的對比
Hibernate和MyBatis都有相應的代碼生成工具。可以生成簡單基本的DAO層方法。針對高級查詢，Mybatis需要手動編寫SQL語句，以及ResultMap。而Hibernate有良好的映射機制，開發者無需關心SQL的生成與結果映射，可以更專注於業務流程。
第三方面：sql優化方面
Hibernate的查詢會將表中的所有欄位查詢出來，這一點會有性能消耗。Hibernate也可以自己寫SQL來指定需要查詢的欄位，但這樣就破壞了Hibernate開發的簡潔性。而Mybatis的SQL是手動編寫的，所以可以按需求指定查詢的欄位。
Hibernate HQL語句的調優需要將SQL列印出來，而Hibernate的SQL被很多人嫌棄因為太丑了。MyBatis的SQL是自己手動寫的所以調整方便。但Hibernate具有自己的日誌統計。Mybatis本身不帶日誌統計，使用Log4j進行日誌記錄。
第四方面：對象管理的對比
Hibernate 是完整的對象/關系映射解決方案，它提供了對象狀態管理（state management）的功能，使開發者不再需要理會底層資料庫系統的細節。也就是說，相對於常見的 JDBC/SQL 持久層方案中需要管理 SQL 語句，Hibernate採用了更自然的面向對象的視角來持久化 Java 應用中的數據。
換句話說，使用 Hibernate 的開發者應該總是關注對象的狀態（state），不必考慮 SQL 語句的執行。這部分細節已經由 Hibernate 掌管妥當，只有開發者在進行系統性能調優的時候才需要進行了解。而MyBatis在這一塊沒有文檔說明，用戶需要對對象自己進行詳細的管理。
第五方面：緩存機制
⑷ 在mybatis中executortype的值包括哪些
在mybatis中executortype的值包括默認的執行器SIMPLE、執行器重用REUSE、執行器重用語句批量更新BATCH。
⑸ Apache Felix 進行web 開發 怎麼和spring mvc 和 mybatis 整合
在J2EE領域，Hibernate與Mybatis是大家常用的持久層框架，它們各有特點，在持久層框架中處於領導地位。
本文主要介紹Mybatis（對於較小型的系統，特別是報表較多的系統，個人偏向Mybatis），對於它，個人比較喜歡的是：
使用簡單、方便；
支持的XML動態SQL的編寫，方便瀏覽、修改，同時降低SQL與應用程序之間的耦合。
不喜歡的是：
出現錯誤時，調試不太方便
本文主要介紹Mybatis的搭建，是學習Mybatis過程後整理的札記，其中包括「單獨搭建Myts」和常用的「Mybatis與Spring的整合」。
一、資料庫的准備
因為Mybatis是持久層框架，毫無疑問，是需要操作資料庫的。所以，在搭建之前，我們需要先創建一個簡單的表。
SQL - DDL - Create Table
插入一些數據，以作查詢的測試。
SQL - DML - Insert table
二、單獨搭建Myts
1）環境准備、版本說明
此工程使用JDK1.6 + mybatis-3.2.4 + Oracle11g。
新建一個Web工程，由於只構建Mybatis，只引用Mybatis和Oracle JDBC驅動包
mybatis-3.2.4.jar
ojdbc6.jar
2）程序的搭建
首先，我們將數據源等配置信息放在一個xml，讓Mybatis可以根據這個信息去連接資料庫、管理事務。
目前我們可只關注environments節點，此節點是用於配置數據源、事務管理的 。
其他的節點，如typeAliases、mappers，是用於注冊一些信息的，後面會陸續提到。
mybatis-config.xml
既然有了配置的xml，下一步就需要讓Mybatis載入它了。
首先以輸入流的形式載入xml
以「SqlSessionFactoryBuilder -> SqlSessionFactory -> SqlSession」的流程最後構建出SqlSession。
SqlSession，顧名思義，是一次會話，是應用程序與資料庫交互的會話，所以，其生命周期應在一次資料庫連接之間，當然，此次資料庫連接可以包含一次或多次資料庫操作。
SqlSessionFactory，顧名思義，是SqlSession的工廠類，用於產出SqlSession。我們知道，SqlSession主要用於資料庫操作，而資料庫操作又是貫穿於應用程序整個生命周期當中的，那麼，"產出SqlSession"這個動作也應當貫穿於應用程序整個生命周期當中，所以，SqlSessionFactory的生命周期一般為應用程序的整個生命周期，一般為單例/static的形式存在。
SqlSessionFactoryBuilder，由代碼可見，其主要作用是從配置文件中獲取配置信息，然後構建SqlSessionFactory，所以其生命周期可以是臨時的，局部的。
通過SqlSession獲取UserMapper介面，再調用該介面的數據操縱方法。
⑹ Hibernate和MyBatis哪個好
使用Hibernate進行編程有以下好處：
1，消除了代碼的映射規則，它全部分離到了xml或者註解裡面去配置。
2，無需在管理資料庫連接，它也配置到xml裡面了。
3，一個會話中不需要操作多個對象，只需要操作Session對象。
4，關閉資源只需要關閉一個Session便可。
這就是Hibernate的優勢，在配置了映射文件和資料庫連接文件後，Hibernate就可以通過Session操作，非常容易，消除了jdbc帶來的大量代碼，大大提高了編程的簡易性和可讀性。Hibernate還提供了級聯，緩存，映射，一對多等功能。Hibernate是全表映射，通過HQL去操作pojo進而操作資料庫的數據。
Hibernate的缺點：
1，全表映射帶來的不便，比如更新時需要發送所有的欄位。
2，無法根據不同的條件組裝不同的SQL。
3，對多表關聯和復雜的sql查詢支持較差，需要自己寫sql，返回後，需要自己將數據封裝為pojo。
4，不能有效的支持存儲過程。
5，雖然有HQL，但是性能較差，大型互聯網系統往往需要優化sql，而hibernate做不到。
Mybatis：
為了解決Hibernate的不足，Mybatis出現了，Mybatis是半自動的框架。之所以稱它為半自動，是因為它需要手工匹配提供POJO，sql和映射關系，而全表映射的Hibernate只需要提供pojo和映射關系即可。
Mybatis需要提供的映射文件包含了一下三個部分：sql，映射規則，pojo。在Mybatis裡面你需要自己編寫sql，雖然比Hibernate配置多，但是Mybatis可以配置動態sql，解決了hibernate表名根據時間變化，不同條件下列不一樣的問題，同時你也可以對sql進行優化，通過配置決定你的sql映射規則，也能支持存儲過程，所以對於一些復雜和需要優化性能的sql查詢它就更加方便。Mybatis幾乎可以做到jdbc所有能做到的事情。
什麼時候使用Hibernate，Mybatis
Hibernate作為留下的Java orm框架，它確實編程簡易，需要我們提供映射的規則，完全可以通過IDE生成，同時無需編寫sql確實開發效率優於Mybatis。此外Hibernate還提供了緩存，日誌，級聯等強大的功能，但是Hibernate的缺陷也是十分明顯，多表關聯復雜sql，數據系統許可權限制，根據條件變化的sql，存儲過程等場景使用Hibernate十分不方便，而性能又難以通過sql優化，所以註定了Hibernate只適用於在場景不太復雜，要求性能不太苛刻的時候使用。
如果你需要一個靈活的，可以動態生成映射關系的框架，那麼Mybatis確實是一個最好的選擇。它幾乎可以替代jdbc，擁有動態列，動態表名，存儲過程支持，同時提供了簡易的緩存，日誌，級聯。但是它的缺陷是需要你提供映射規則和sql，所以開發工作量比hibernate要大些。
⑺ 如何生成ibatis 動態sql
IBATIS：最大的優點是可以有效的控制sql發送的數目，提高數據層的執行效率！好象阿里巴巴現在就用的是IBATIS；它需要程序員自己去寫sql 語句，不想hibernate那樣是完全面向對象的，自動化的，ibatis是半自動化的，通過表和對象的映射以及手工書寫的sql語句，能夠實現比 hibernate等更高的查詢效率。
給個文章你參考下：
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提供的思路是我們應該仔細考慮的。
⑻ struts2怎麼防止sql注入
sql注入大家都不陌生，是一種常見的攻擊方式，攻擊者在界面的表單信息或url上輸入一些奇怪的sql片段，例如「or 『1』=』1』」這樣的語句，有可能入侵參數校驗不足的應用程序。所以在我們的應用中需要做一些工作，來防備這樣的攻擊方式。在一些安全性很高的應用中，比如銀行軟體，經常使用將sql語句全部替換為存儲過程這樣的方式，來防止sql注入，這當然是一種很安全的方式，但我們平時開發中，可能不需要這種死板的方式。
一起jquery,17jquery
mybatis框架作為一款半自動化的持久層框架，其sql語句都要我們自己來手動編寫，這個時候當然需要防止sql注入。其實Mybatis的sql是一個具有「輸入+輸出」功能，類似於函數的結構，如下：
一起jquery,17jquery
<</span>select id="getBlogById" resultType="Blog" parameterType=」int」>
17jquery.com
select id,title,author,content 內容來自17jquery
from blog where id=#{id} 一起jquery,17jquery
</</span>select> 內容來自17jquery
這里，parameterType標示了輸入的參數類型，resultType標示了輸出的參數類型。回應上文，如果我們想防止sql注入，理所當然地要在輸入參數上下功夫。上面代碼中高亮部分即輸入參數在sql中拼接的部分，傳入參數後，列印出執行的sql語句，會看到sql是這樣的：
內容來自17jquery
select id,title,author,content from blog where id = ?
一起jquery,17jquery
不管輸入什麼參數，列印出的sql都是這樣的。這是因為mybatis啟用了預編譯功能，在sql執行前，會先將上面的sql發送給資料庫進行編譯，執行時，直接使用編譯好的sql，替換佔位符「？」就可以了。因為sql注入只能對編譯過程起作用，所以這樣的方式就很好地避免了sql注入的問題。
一起jquery,17jquery
mybatis是如何做到sql預編譯的呢？其實在框架底層，是jdbc中的PreparedStatement類在起作用，PreparedStatement是我們很熟悉的Statement的子類，它的對象包含了編譯好的sql語句。這種「准備好」的方式不僅能提高安全性，而且在多次執行一個sql時，能夠提高效率，原因是sql已編譯好，再次執行時無需再編譯。 一起jquery,17jquery
話說回來，是否我們使用mybatis就一定可以防止sql注入呢？當然不是，請看下面的代碼：
17jquery.com
<</span>select id="orderBlog" resultType="Blog" parameterType=」map」>
17jquery.com
select id,title,author,content 一起jquery,17jquery
from blog order by ${orderParam}
17jquery.com
</</span>select>
內容來自17jquery
仔細觀察，內聯參數的格式由「#{xxx}」變為了${xxx}。如果我們給參數「orderParam」賦值為」id」,將sql列印出來，是這樣的：
內容來自17jquery
select id,title,author,content from blog order by id
一起jquery,17jquery
顯然，這樣是無法阻止sql注入的。在mybatis中，」${xxx}」這樣格式的參數會直接參與sql編譯，從而不能避免注入攻擊。但涉及到動態表名和列名時，只能使用「${xxx}」這樣的參數格式，所以，這樣的參數需要我們在代碼中手工進行處理來防止注入。 一起jquery,17jquery
結論：在編寫mybatis的映射語句時，盡量採用「#{xxx}」這樣的格式。若不得不使用「${xxx}」這樣的參數，要手工地做好過濾工作，來防止sql注入攻擊。
⑼ ibatis動態sql配置啟動時提示：The content of elements must consist of well-formed character data...
把下面這個表達式反過來寫就可以了。
如圖：
⑽ 避免mysql注入應該避免有哪些特殊字元
特殊字元有：
SQL中通配符的使用
SQL注入式攻擊，就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字元串，欺騙伺服器執行惡意的SQL命令。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態SQL命令，或作為存儲過程的輸入參數，這類表單特別容易受到SQL注入式攻擊。