資訊專欄INFORMATION COLUMN
摘要：要是緊急排查個問題，媽蛋雖然有很多好處，比如和底層的無關。你的公司如果有，是不允許你亂用的。
知乎看到問題《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層，要學一些費力不討好的東西。
Listpersons = queryFactory.selectFrom(person) .where(person.children.size().eq( JPAExpressions.select(parent.children.size().max()) .from(parent))) .fetch();
看看上面的查詢語句，完全不如普通SQL表達的清晰。要是緊急排查個問題，媽蛋...
jpa雖然有很多好處，比如和底層的SQL無關。但我覺得Spring Data JPA有以下壞處：
1、 屏蔽了SQL的優雅，發明了一種自己的查詢方式。這種查詢方式并不能夠覆蓋所有的SQL場景。
2、 增加了代碼的復雜度，需要花更多的時間來理解DAO
3、DAO操作變的特別的分散，分散到多個java文件中，或者注解中（雖然也支持XML）。如果進行一些掃描，或者優化，重構成本大
4、不支持復雜的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還有一個好處，那就是帥鍋啊
END來，越年輕越狂妄的家伙們，來噴我啊。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/74763.html
摘要：一從零搭建環境本次我使用的是編輯器來搭建和環境首先，我們在新建項目的時候，選擇，然后就行了。可以看出，本次的版本為。這是一個非常好用的插件，有了它我們可以不用寫繁瑣的方法。非常適合我們做一些簡答的測試和小功能。 前言 只有光頭才能變強。 文本已收錄至我的GitHub倉庫，歡迎Star：https://github.com/ZhongFuCheng3y/3y 不知道大家對SpringB...
摘要：而本身也是基于的實現。有點類似于實現類和接口的關系。而是在兩者的肩膀上更近一步，提供了更加方便的操作。順帶一說，與兩者不同，它不基于協議，而是直接通過操作語句來操作數據庫。 人生苦短，我用 SDJ！ Spring Data JPA（SDJ）在我看來，相比于 MyBatis 和 Hibernate 最大的好處就在于，它太方便了！如果你的業務邏輯并不需要控制細膩度很高的情況下（SDJ 在我...
摘要：我將舉幾個栗子，來詳細的說一下我自己在使用多表復雜查詢的場景和想法。名字手機號這是一個單表的多條件復雜查詢，由于是在幾個屬性中進行篩選，其中的屬性的個數不知道有多少個，所以只需要利用查詢就可以很方便的實現這個需求。 最近工作中由于要求只能用hibernate+jpa 與數據庫進行交互，在簡單查詢中，jpa繼承CrudRepository接口 ，然后利用jpa的方法命名規范進行jpql查...
摘要：不管是還是，表之間的連接查詢，被映射為實體類之間的關聯關系，這樣，如果兩個實體類之間沒有實現關聯關系，你就不能把兩個實體或者表起來查詢。 因為項目需要選擇數據持久化框架，看了一下主要幾個流行的和不流行的框架，對于復雜業務系統，最終的結論是，JOOQ是總體上最好的，可惜不是完全免費，最終選擇JDBC Template。 Hibernate和Mybatis是使用最多的兩個主流框架，而JOO...
摘要：所以悲觀鎖是限制其他線程，而樂觀鎖是限制自己，雖然他的名字有鎖，但是實際上不算上鎖，只是在最后操作的時候再判斷具體怎么操作。悲觀鎖和樂觀鎖比較悲觀鎖適合寫多讀少的場景。 最近在公司的業務上遇到了并發的問題，并且還是很常見的并發問題，算是低級的失誤了。由于公司業務相對比較復雜且不適合公開，在此用一個很常見的業務來還原一下場景，同時介紹悲觀鎖和樂觀鎖是如何解決這類并發問題的。 公司業務就是...
閱讀 1026·2021-11-23 09:51
閱讀 2344·2021-10-08 10:22
閱讀 2544·2021-09-29 09:35
閱讀 853·2021-09-22 15:20
閱讀 2858·2019-08-30 15:53
閱讀 2412·2019-08-30 13:55
閱讀 1096·2019-08-29 17:27
閱讀 2869·2019-08-29 17:26
