對(duì)于一個(gè)和數(shù)據(jù)庫(kù)打交道的程序員來說,很快會(huì)面臨著一個(gè)艱難的選擇。到底是選擇MyBatis
還是JPA
呢?
很多人說,技術(shù)選擇,都要根據(jù)需求來,這個(gè)沒錯(cuò)。但是,除了需求,還有很重要的一個(gè)環(huán)節(jié),那就是隊(duì)友的水平。如果你選擇了一些比較高級(jí)的技術(shù),那么就是在給整個(gè)團(tuán)隊(duì)埋坑。
JPA的抽象層次更高,代碼寫起來也更簡(jiǎn)潔,但是它一點(diǎn)都不簡(jiǎn)單。雖然經(jīng)過了多次的培訓(xùn),我呆過的幾個(gè)團(tuán)隊(duì),還是把它用的和屎一樣。
我扔掉了JPA
我仔細(xì)想了一下,有下面幾點(diǎn)原因,造成了JPA在很多團(tuán)隊(duì)根本就玩不下去。
- JPA適合業(yè)務(wù)模型固定的場(chǎng)景,適合比較穩(wěn)定的需求。但是國(guó)內(nèi)這種朝三暮四的需求風(fēng)格,產(chǎn)品經(jīng)理這種傳話筒式的設(shè)計(jì)模式,造成了需求的泛濫和不確定。JPA在這種模式下就是渣。
- JPA的技術(shù)要求比較高。不要懷疑,你剛開始用起里可能覺得非常簡(jiǎn)單。但隨著你的深入使用,你會(huì)發(fā)現(xiàn)這是一個(gè)災(zāi)難。里面的各種轉(zhuǎn)換和緩存,會(huì)把人繞暈。而大多數(shù)的快餐程序員是不想要了解這些的。
- 很多程序員很會(huì)寫SQL,所以很多SQL語(yǔ)句長(zhǎng)的很胖,長(zhǎng)的要命。業(yè)務(wù)混亂,多張表關(guān)聯(lián),我甚至見過上百?gòu)垬I(yè)務(wù)表關(guān)聯(lián)的復(fù)雜業(yè)務(wù)。DBA無奈之下,通常都會(huì)有sql審核。JPA搞sql審核?還是弱了一點(diǎn)。
所以,不是JPA不好,而是它不符合國(guó)情而已。想要在公司內(nèi)推行JPA,你需要給我一個(gè)穩(wěn)定的產(chǎn)品團(tuán)隊(duì)、一個(gè)牛X的技術(shù)團(tuán)隊(duì)才行。
所以,大多數(shù)公司寧可寫一堆重復(fù)的、亂七八糟的 MyBatis 代碼,也不會(huì)輕易嘗試JPA,這是符合邏輯的,符合事物發(fā)展規(guī)律的。
所以,我們下面的文章就是來討論 MyBatis 的,來看一下 MyBatis 到底要怎么寫才算優(yōu)雅。
MyBatis為什么不好用
優(yōu)秀的程序員都是很懶的。所以很多人不想設(shè)計(jì)實(shí)體的 sql。 JPA 可以直接根據(jù) Java 的實(shí)體代碼,生成 sql 的庫(kù)表,這在使用 MyBatis 的人來看,是非常羨慕的。
使用MyBatis,要倒著來。需要先設(shè)計(jì)庫(kù)表,然后根據(jù)庫(kù)表反向生成一堆Java代碼和配置文件。
這個(gè)代碼生成器,就是mybatis-generator
。
但是,請(qǐng)注意。這個(gè)生成器生成的代碼,有四種
模式?。?!這就是最讓初學(xué)者難受的地方。如果你也是剛接觸MyBatis,強(qiáng)烈推薦只關(guān)注下面第一種模式。
- MyBatis3 這種模式就是我們常用的方式,會(huì)生成domain類、Example類、mapper映射文件等。它生成的信息比較啰嗦,內(nèi)容幾乎無法改動(dòng)。對(duì)于項(xiàng)目中自己寫的sql,一般都采用手寫的方式再寫一份,而不是改動(dòng)原來的文件。
- MyBatis3Simple 上面這種模式的簡(jiǎn)易代碼生成模式,缺少一些東西,但很簡(jiǎn)潔。對(duì)MyBatis沒有經(jīng)驗(yàn),不推薦使用它。
- MyBatis3DynamicSql 這是通過Builder模式實(shí)現(xiàn)的動(dòng)態(tài)SQL特性,你還需要加入額外的jar包。加上它之后,其實(shí)和JPA是有點(diǎn)相似的。既然如此,那為何不直接使用JPA呢?所以這個(gè)DSQL雖然是默認(rèn)的生成行為,但是非常不推薦。
- MyBatis3Kotlin 這個(gè)不廢話。就是生成Kotlin版的一些配置和代碼信息。
所以,下面僅僅介紹MyBatis3
模式的代碼生成。
要使用它,需要在pom.xml里加入它的依賴。
org.mybatis.generator
mybatis-generator-core
true
test
1.4.0
我個(gè)人喜歡使用 Java 代碼來操作代碼生成這個(gè)過程,所以下面就是生成代碼的代碼。
public class MBGTool {
public static void main(String[] args) throws Exception {
List warnings = new ArrayList();
boolean overwrite = true;
InputStream configFile = MBGTool.class.getResourceAsStream("/generator/generatorConfig.xml");
ConfigurationParser cp = new ConfigurationParser(warnings);
Configuration config = cp.parseConfiguration(configFile);
DefaultShellCallback callback = new DefaultShellCallback(overwrite);
MyBatisGenerator myBatisGenerator = new MyBatisGenerator(config, callback, warnings);
myBatisGenerator.generate(null);
}
}
從代碼中,我們可以看到需要配置一個(gè)generatorConfig.xml
文件,用來規(guī)定怎么生成代碼文件。
<table tableName="test"/>
運(yùn)行我們的MBGTool
文件之后,就可以生成 MyBatis 的代碼了。
怎么寫代碼最優(yōu)雅
但是,我這里并不是要推薦你使用這種模式。因?yàn)?,它生成了一大堆無用的文件。假如你的項(xiàng)目使用了 sonar 這樣的代碼質(zhì)量審查工具,你會(huì)發(fā)現(xiàn)很多飄紅的地方,還有那要命的覆蓋率問題。
怎么辦?
經(jīng)過我多年的摸索,我現(xiàn)在推薦一種非常好用的寫法。自從我采用了這種方式之后,就再也沒有換過。
第一、不需要代碼生成器了
數(shù)據(jù)表的設(shè)計(jì),還有 domain 的書寫,全部靠手工。這樣我們的代碼,如果有必要,還可以遷移到 JPA 上去。這種模式還能順便學(xué)習(xí)一下 Java 里面的數(shù)據(jù)類型,是如何和 SQL 里的數(shù)據(jù)類型一一對(duì)應(yīng)的。在做表設(shè)計(jì)的時(shí)候,順便能夠了解一些背后的原理。
第二、不需要寫映射文件了
生成器生成的東西,確實(shí)是有一堆無用的邏輯。比如我的某個(gè)數(shù)據(jù)表,根本不需要提供查詢所有和刪除這種動(dòng)作,它還是默認(rèn)提供了。
在這種簡(jiǎn)約模式下,我們直接手寫 Mapper 文件,然后只聲明所需要的接口方法就可以了。
@Mapper
public interface AccountBasicMapper {
@Insert("AccountBasicMapper/insert.sql")
void insert(@Param("r") AccountBasic record);
}
可以看到,里面有一個(gè) Insert 注解,我們傳入了一個(gè)具體的 domain,然后,就可以在AccountBasicMapper
目錄下的insert.sql
文件里,書寫具體的 sql 語(yǔ)句了。
sql語(yǔ)句樣例如下:
INSERT INTO account_basic(
account_id,
nick_name,
password,
sex,
state,
photo_url,
created,
modified,
version
)VALUES (
,
,
,
,
,
,
,
,
)
那么這是什么語(yǔ)法呢?它又是如何知道是這樣配置的呢?這就需要引入 MyBatis 的腳本語(yǔ)言配置功能。在這里,我們使用的freemark
的模版。
不要忘了加入它的依賴。
org.mybatis.scripting
mybatis-freemarker
1.2.2
然后,在yaml文件里做上相應(yīng)的配置就ok了。
mybatis:
check_config_location: false
scripting-language-driver:
freemarker:
template-file:
base-dir: mappers/
path-provider:
includes-package-path: false
separate-directory-per-mapper: false
這種方式的好處和壞處
我個(gè)人是非常喜歡這種模式的。因?yàn)樗邢旅鎺讉€(gè)好處:
- 用什么寫什么,代碼量少,簡(jiǎn)潔優(yōu)雅。
- SQL集中,不用分散在代碼里,xml里,或者注解里。方便DBA進(jìn)行SQL審核。由于沒了xml的干擾,SQL反而更加簡(jiǎn)潔了。
- 一個(gè)DAO方法一個(gè)sql文件,模式單一可控。
- MyBatis的功能優(yōu)勢(shì)可以全部發(fā)揮,無縫集成。
當(dāng)然,缺點(diǎn)也是顯而易見的。
- 即使變了個(gè)參數(shù),也要修改很多sql文件。
- 需要為每一個(gè)方法配一個(gè)sql文件,即使這是個(gè)很弱智的插入查詢方法。
不過,我并不認(rèn)為這是個(gè)問題。每一個(gè)方法配備一個(gè)sql文件,代碼寫起來反而更加簡(jiǎn)單了。當(dāng)出現(xiàn)問題的時(shí)候,也不用根據(jù)邏輯進(jìn)行跟蹤定位到拼接后的 SQL 語(yǔ)句。我現(xiàn)在,只需要拿到對(duì)應(yīng)方法的 SQL 文件,就可以改吧改吧,直接在 sql 終端里執(zhí)行調(diào)試。這樣,sql 優(yōu)化也變的簡(jiǎn)單了。
當(dāng)然,一個(gè)人一個(gè)習(xí)慣。我個(gè)人喜歡這種模式,而且在我的團(tuán)隊(duì)里推行這種模式,發(fā)現(xiàn)運(yùn)行的也很好。另外,程序員為了少寫重復(fù)的 sql 代碼,在設(shè)計(jì)Dao接口的時(shí)候,反而更加認(rèn)真了。
這可能是一個(gè)額外的收獲吧。
文章來源于公眾號(hào):猿邏輯 ,作者小Q
以上就是W3Cschool編程獅
關(guān)于MyBatis還是JPA?終于有答案了!的相關(guān)介紹了,希望對(duì)大家有所幫助。