引戰貼,沒養分,忽略。php
更多精彩文章。java
《「分庫分表" ?選型和流程要慎重,不然會失控》spring
《程序員畫像,十年沉浮》vim
最有用系列:網絡
《Linux生產環境上,最經常使用的一套「vim「技巧》mybatis
知乎看到問題《SpringBoot開發使用Mybatis仍是Spring Data JPA??》,順手一答,討論激烈。我實在搞不懂spring data jpa爲啥選了hibernate做爲它的實現,是「Gavin King」的裙帶關係麼? DAO層搞來搞去,從jdbc到hibernate,從toplink到jdo,到如今MyBatis勝出,是有緣由的。
目前,一些狗屁培訓公司,還有一些網絡課程,包括一些洋課程,爲了作項目簡單,不少會使用jpa。但到了公司發現根本就不是這樣,這就是理論和現實的區別。
頂着被罵的風險,我整理髮出來。這可不是爭論php好仍是java好性質了。
忠告:精力有限,必定要先學MyBatis啊。jpa那一套,表面簡單而已。
若是你經歷過多個公司的產品迭代,尤爲是複雜項目,你就會發現Spring Data JPA
這種東西是多麼的不討好。說實話,Mybatis
的功能有時候都嫌多,有些純粹是多此一舉。
jpa
雖然是規範,但和hibernate
這種ORM
是長得比較像的(不說一些特殊場景的用法)。
Spring Data JPA 是個玩具,只適合一些簡單的映射關係。也不得不提一下被人吹捧的querydsl
,感受有些自做聰明的討巧。實在不想爲了一個簡單的DAO層,要學一些費力不討好的東西。
List<Person> persons = queryFactory.selectFrom(person)
.where(person.children.size().eq(
JPAExpressions.select(parent.children.size().max())
.from(parent)))
.fetch();
複製代碼
看看上面的查詢語句,徹底不如普通SQL
表達的清晰。要是緊急排查個問題,媽蛋...
jpa雖然有不少好處,好比和底層的SQL無關。但我以爲Spring Data JPA有如下壞處:
一、 屏蔽了SQL的優雅,發明了一種本身的查詢方式。這種查詢方式並不可以覆蓋全部的SQL場景。
二、 增長了代碼的複雜度,須要花更多的時間來理解DAO
三、DAO操做變的特別的分散,分散到多個java文件中,或者註解中(雖然也支持XML)。若是進行一些掃描,或者優化,重構成本大
四、不支持複雜的SQL,DBA流程很差切入
Mybatis雖然也有一些問題,但你更像是在寫確切的SQL。它比Spring Data JPA更加輕量級。
你只要在其餘地方調試好了SQL,只須要寫到配置文件裏,起個名字就能夠用了,少了不少燒腦的轉換過程。
Mybatis徹底可以應對工業級的複雜SQL,甚至存儲過程(不推薦)。我的認爲Mybatis依然是搞複雜了,它其中還加了一些相似if else的編程語言特性。
你的公司若是有DBA,是不容許你亂用SQL的。用Mybatis更能切入到公司的流程上。
因此我認爲:玩具項目或者快速開發,使用Spring Boot JPA。反之,Mybatis是首選。
你說的if else是指的SQL拼接吧,這但是MyBatis的重要功能之一,學起來一點兒也不復雜好嗎?
最近也在研究持久層,能夠充分利用這個jpa這個玩具,二者結合是不錯的選擇,jpa基本的單表操做,mybatis作複雜查詢,開發效率高,下降sql維護成本,也爲優化留下空間,固然這須要對spring-data-jpa作一些擴展
查詢直接sql,其餘的仍是orm方便
mybatis主要是原生sql,對於其餘沒學習過jpa的開發人員而言下降了學習維護門檻,並且說真的jpa寫了個鍋你去追其實仍是挺頭疼的...
mybatis-plus整合以後基本curd不用糾結了,不少對對象操做而後直接save就好。複雜場景、聯表就直接用原生sql就好,至於性能問題能夠用sqlAdvice優化下。
jdbc template+代碼生成器,更簡單更高效
jpa這玩意,寫一個簡單的數據庫操做,就好比說單表的操做,很好用。若是是多表,那就算了吧
spring boot 推薦jpa,知道爲何嗎
native=true 想用原生查詢也沒人攔着你啊
你好像不是很懂hibernate和jpa…
不知道你是否清楚 jpa,hibernate,spring data jpa,還有querydsl 之間的關係。
總有一天你會知道數據庫優先和程序優先的區別
jpa還有一個好處,那就是帥鍋啊
來,越年輕越狂妄的傢伙們,來噴我啊。