MyBatis知多少（2）

MyBatis從目前最流行的關係數據庫訪問方法中吸取了大量的優秀特徵和思想，並找出其中的協同增效做用。下圖展現了MyBatis框架是如何吸取咱們在多年使用不一樣方式進行數據庫集成的 開發過程當中所學到的知識，並將其中最優秀的思想結合起來，造成這個混合型解決方案的。

 接下來的幾節將討論這些不一樣的數據庫訪問方法，以及iBATIS從每種方法中汲取的優秀思想。

SQL

MyBatis的核心是SQL。從根本上說，全部的關係數據庫都支持SQL,並將它做爲與數據庫交互的主要方式。SQL是一種簡單的、非過程化的語言，用於操縱數據庫，其實SQL包含兩種語言。

第一種就是數據定義語言（Data Definition Language, DDL),其中包含像CREATE、DROP以 及ALTER這樣的語句。這些語句用於定義數據庫數據及其設計，包括表（table)、列（column)、 索引（index)、約束（constraint)、過程（procedure)以及外鍵關係（foreign key relationship)。iBATIS 並不直接支持DDL。雖然許多人的確經過iBATIS成功地執行了DDL，但咱們不推薦這樣作，由於 DDL一般應該由某個數據庫管理小組擁有並控制，應用程序的開發人員無權操縱它。

SQL所包含的第二種語言就是數據操縱語句（Data Manipulation Language，DML)。DML包

括像SELECT、INSERT、UPDATE以及DELETE這樣的用於直接操縱數據的語句。最初，SQL被設計 爲一種簡單得足以讓終端用戶（end user)可使用的語言。按照這種設計思想，圖像用戶界面 就徹底不須要了，甚至連應用程序也不須要了。固然，這種狀況得回溯到當年那個永遠是「黑屏 上閃着光標」的時代了，在那個時代咱們才能夠對終端用戶報以更多的指望。

今非昔比，數據庫已經變得太複雜了，不能期望終端用戶經過SQL來直接操縱數據庫了。你 能想象這樣的狀況嗎：將一大堆SQL語句交給會計部門，而後對他說，「就這些了，查找一下 BSHEET表你就能找到所須要的信息。」這簡直是不可能的了。

僅僅SQL自己已經不再可能做爲終端用戶的一個有效接口 了，但對於開發人員來講SQL仍 然是一個很是強大的工具。SQL是惟一具備完整的數據庫訪問功能的方法，全部其餘的工具都不 過是該完整功能的一個子集。正是這個緣由，MyBatis徹底支持SQL，並將它做爲關係數據庫訪問 的主要方式。同時，MyBatis也具備許多其餘方法的優勢，這些方法包括存儲過程和對象/關係映 射工具。

1.老式存儲過程

存儲過程（stored procedure)也許能夠算是爲關係數據庫編寫應用程序的最古老的方式了。 許多遺留系統使用的都是咱們如今稱爲「兩層（two-tier)」的設計。「兩層設計」包括一個富客戶 端界面來直接調用數據庫中的存儲過程。這些存儲過程當中可能包含可用於操縱當前數據庫的 SQL。除了SQL,這些存儲過程還可能含有（一般也的確含有）業務邏輯。與SQL不一樣，編寫這 些存儲過程時使用的語言是過程化的，具備像條件語句和迭代語句這樣的流程控制語句。事實上， 僅僅使用存儲過程就能夠建立一個完整的應用程序。許多軟件開發商也開發了像Oracle Forms、 PowerBuilder和Visual Basic這樣的富客戶端工具來支持「兩層」的數據庫應用程序的開發。

「兩層應用程序」的最大問題在於其性能和擴展性。雖然數據庫的功能的確很是強大，但它 們每每未必是處理成百上千甚至上百萬個用戶訪問的最佳選擇。對於現代Web應用程序來講，對 擴展性的需求並很多見。數據庫在併發訪問量、硬件資源以及網絡套接字等方面的限制，將使得 這種「兩層」架構在須要擴大規模時面臨失敗的危險。此外，「兩層應用程序」的部署也是一場 噩夢。除了一般的富客戶端部署問題外，複雜的運行時數據庫引擎也須要部署到客戶端機器上去。

2.現代存儲過程

在某些圈子中存儲過程仍被認爲是三層（three-tier)和八層(N-tier)應用程序（例如Web應 用程序）的最佳實踐。但如今存儲過程一般被看成來自中層（middle tier)的遠程過程調用（remote procedure call, RPC),而且許多性能方面的約束也能夠經過創建間接池和數據庫資源管理等方式 解決了。在現代的面向對象的應用程序中，存儲過程仍然是實現完整的數據訪問層的一個行之有 效的設計選擇。存儲過程在性能方面的確具備優點，由於它們老是可以比任何其餘的解決方案更 快地完成數據庫中的數據操做。可是，還有比性能更須要關注的問題。

將業務邏輯放在存儲過程當中一般都被認爲是一個糟糕的設計。最主要的緣由就在於存儲過程 的開發很難符合現代應用程序的架構。它們難以編寫、難以測試、同時也難以部署。更糟糕的是， 現代企業中數據庫一般由其餘的數據庫管理小組擁有，而且受到最爲嚴格的變動控制的保護。它 們一般沒法快速變動以適應現代軟件開發方法學的須要。此外，要用存儲過程來實現完整的業務 邏輯，其自身也存在某些限制。若是業務邏輯須要訪問其餘的系統、資源或用戶界面，存儲過程 極可能就沒法處理全部這些邏輯了。現代應用程序很是複雜，須要更加通用的語言，而不是像存 儲過程這樣僅僅優化了數據操縱能力的專用語言。爲解決這個問題，有些開發商在它們的數據庫 引擎中嵌入了像Java這樣的更增強大的語言，來編寫更增強壯的存儲過程。但這其實根本沒有解 決問題，它只會使得應用程序與數據庫的邊界變得更加模糊，併爲數據庫管理員帶來新的負擔： 他們如今須要開始擔憂數據庫中的Java和C#了。對於解決問題，這實在是一個錯誤的工具。

軟件開發中常常出現的一個場景就是矯枉過正（overcorrection)。當發現問題時，嘗試的第一個解決方案每每是徹底相反的方法。這非但沒有解決問題，其結果每每是引入等量的徹底不一樣的新問題。例如咱們下面要討論的內聯SQL。

系列文章：

MyBatis知多少（1）