問答專欄Q & A COLUMN
頭條上問這種問題也是醉了。。看到了順便答一波，瞎扯的人太多。
國內的設計思路是table driven的，簡單來說，用數據表定邏輯，用模型做實現，實際這是和面向對象相反的思路。mybatis所謂的靈活性在大多數工程師手里就是不用考慮模型如何設計，“反正我用原生sql都能解決”，模型設計的爛的一逼，全靠sql去修修補補。而jpa是完全object driven的思路，前期設計的缺陷會很制約后續開發，并且不同的數據庫可做不同的實現（實際是哪怕是redis也是一樣的）。回答幾個常見sb問題。
1.jpa表連接行為不確定，難以控制。
你確定你用過spring data jpa？不知道有EntityGraph ？傻瓜到這種程度了還能咋的。
2.jpa子查詢不好實現。
我估計你都沒用過吧？spring data jpa的子查詢既可以多帶帶定義視圖，也可以做subquery，甚至直接用jpql。
3.jpa不好優化。
我真不信99%得優化能超過spring data jpa的優化，尤其是一般般的程序員能別把優化放嘴上么，連mysql的鎖都搞不清楚，表設計的跟坨屎一樣還天天原生sql，覺得自己很牛逼么？jpa是可以把表屬性反應到對象的，天然就有運行時優化的底子在，ORM能發展的空間太大了，稍微有點技術認知的都知道ORM會優勢越來越大。稍微有些經歷的程序員都知道現在是先說好維護才說其他的，能解決性能的方法太多了好么。
最后，難道不知道現在提倡ORM+CQRS么？請問，有啥復雜的解決不了，都不需要native sql介入好么。
評論0
加載中...
個人認為mybatis可以做到代碼與SQL解耦，單表查詢用jpa倒是沒什么，要是寫統計或者復雜查詢之類的jpa就不太友好了，需要代碼邏輯跟SQL耦合起來，代碼可讀性和可維護性不好。最近基于jdbcTemplate做了一套自定義動態查詢，也將sql放在了配置文件中，也是為了降耦和提高代碼可讀性，還可以根據業務場景定制很多功能。
評論0
加載中...
這個問題需要真實去使用過，在使用的過程中會發現各自框架的痛點，當你尋找解決方案的時候，你會看其它框架有沒有解決這個問題，這樣你就會領悟到另一個框架的優勢了。
分享一個真實的實戰經歷：
項目剛開始使用原始JDBC方式操作數據庫，自己手動建表不說，手動組裝對象太痛苦，表字段和對象的關系映射寫一堆代碼，這時候就會想如果有個框架能自動把表和對象關系自動映射，并且能夠封裝好使用方法，在初始化時還能自動建表就更好了。
查找方案時發現了SpringDataJpa，仿佛打開了新世界的大門，原來通過寫SQL查詢再轉成對象的增刪改查都不用寫了，表字段和對象的映射也不需要手工寫代碼去匹配可，直接使用，而且可以開啟初始化時自動創建數據庫表。原來需要消耗時間的數據庫操作代碼現在完全不用寫了，簡單的條件查詢，直接調用封裝的方法，快到起飛。但是隨著業務數據的不斷增多，要查詢的條件也越來越復雜，查詢時效越來越慢，漸漸對查詢性能也有了要求。然后就想，在這樣的使用便利上，如果有能便于優化數據庫查詢性能的解決方案就好了。
再次找解決方案，發現了MyBatis，感覺發現了另一個新世界。雖然，它不能直接把表和對象的關系映射自動封裝好，但是它可以直接把操作結果映射成需要的對象，只需要建立對應的數據對象DTO就行，并且多表關聯查詢、復雜條件查詢都可以寫SQL解決，最重要的是SQL和邏輯代碼分析，維護也很方便，SQL優化交給專業的DBA就行，再次好用到起飛。
突然有一天，公司強制要求數據庫從oracle換成MySQL，發現Mybatis因為都是寫的純SQL，原來的SQL語法是oracle的，現在都要改，太依賴數據庫了，不便于換數據源。這時想起了不依賴數據源的JPA。
總結一下個人看法：
JPA使用完全面向對象的的設計思想，一個表就是一個對象，所有的操作直接操作對象就行，方便、快捷，也不需要關注底層數據源問題，但是表之間的關系復雜了、查詢復雜了，這樣的操作不是它的強項。
Mybatis是半面向對象、半面向SQL，SQL與邏輯代碼分離，查詢結果映射成對象，所有操作上層是對象，下層用SQL，數據查詢優化上更加實用，因為是寫原生SQL，所以換數據源可能麻煩。
還是業內的那句老話，沒有絕對“銀彈”，只有適合當前業務發展需要的技術。
評論0
加載中...
評論0
加載中...
看了一些其他人的回答，噴子蠻多的，噴了輪子還不夠還要噴別人sb，不會用。沒必要搞歧視，都是輪子，用來解放生產力的。輪子好不好，根據具體場景來。
但是從普適性上來看，如果本來比較簡單的事情，用了工具之后反而更復雜了，那就應該反思了。沒錯，這里我說的就是jpa。
Jpa確實很多概念都不錯，如果你拿它做個Demo，會發現確實是生產力解放工具，一旦你用到真實項目上，可能就不盡人意了。除非你的項目業務很簡單，不涉及復雜的表關系，因為在單表的模型上jpa確實表現得很優雅，但是哪個實際的業務會如此簡單？做過項目的人都有經驗，不用我多說。
看到這里，很多人就會噴了，Jpa你會不會用呀，querydsl，enetitygraphql，hql這些都可以用來做復雜查詢，你用過沒？
嗯，其實我現在就在用這些東西。這些東西確實能解決問題，但也只是解決能不能的問題。這就回到前面我所說的，本來簡單事情，反而因為工具更復雜了，原來只用寫sql就能解決的問題，現在是不用寫sql了，但是得寫所謂hql，dsl，graqhql，這就造成你不光要搞懂sql怎么寫，還要搞懂用這些玩意怎么去間接生成你想要sql。
其實用上面這些和jpa捆綁在一起的東西的，本身就是jpa短板導致的無奈之舉，這些東西本身和jpa理念是互相矛盾的。
說到這，有些人的言論就變成了，你不會用怪誰，水平不行怪輪子。這是混淆概念，好不好用是工具自身便捷與否，和用的人水平有什么關系。
所以，究竟jpa好不好用，得看你用來做什么了。
評論0
加載中...
兩者并沒有明顯的劣勢。從技術角度講我更喜歡Jpa，因為她是標準，功能上會強一些。但是在企業開發架構選型上可能會選擇mybatis，因為他簡單上手快，半吊子程序員也能寫出性能不錯的代碼，學習成本低，也為企業節約成本。反觀Jpa能掌握精髓的人少而貴。。。。
評論0
加載中...
1、jpa 出的比較早，是面向對象的思想，一個表封裝成一個對象，對單表有比較好的控制。繼承，約束啊，都是面向對象的產物
2、mybatis則是面向sql，比較靈活，你的結果完全來源于sql。可以針對于單表寫結果集合，也可以自己組裝，想要什么完全取決于你的sql。對于復雜應用來講比較靈活。
沒有什么為什么要有，技術只是方式，為業務服務的。為合適的業務選型最合適的技術，這才是做架構的精髓
評論0
加載中...
spring data jpa在復雜查詢上可以使用query+new 構造方法或者視圖的方式去查詢，至于說效率，我想應該是在POJO中使用@OneToMany或者@ManyToMany的注解導致的，一般情況下盡量使用@ManyToOne就可以了
評論0
加載中...
沒人用 mybatis plus嗎？強大的代碼生成器，比jpa還爽的單表查詢，同時還mybatis的xml，靈活的sql不在話下
評論0
加載中...
0
回答0
回答0
回答0
回答10
回答10
回答0
回答0
回答0
回答0
回答
