這個問題需要真實去使用過，在使用的過程中會發現各自框架的痛點，當你尋找解決方案的時候，你會看其它框架有沒有解決這個問題，這樣你就會領悟到另一個框架的優勢了。

分享一個真實的實戰經歷：

項目剛開始使用原始JDBC方式操作數據庫，自己手動建表不說，手動組裝對象太痛苦，表字段和對象的關系映射寫一堆代碼，這時候就會想如果有個框架能自動把表和對象關系自動映射，并且能夠封裝好使用方法，在初始化時還能自動建表就更好了。

查找方案時發現了SpringDataJpa，仿佛打開了新世界的大門，原來通過寫SQL查詢再轉成對象的增刪改查都不用寫了，表字段和對象的映射也不需要手工寫代碼去匹配可，直接使用，而且可以開啟初始化時自動創建數據庫表。原來需要消耗時間的數據庫操作代碼現在完全不用寫了，簡單的條件查詢，直接調用封裝的方法，快到起飛。但是隨著業務數據的不斷增多，要查詢的條件也越來越復雜，查詢時效越來越慢，漸漸對查詢性能也有了要求。然后就想，在這樣的使用便利上，如果有能便于優化數據庫查詢性能的解決方案就好了。

再次找解決方案，發現了MyBatis，感覺發現了另一個新世界。雖然，它不能直接把表和對象的關系映射自動封裝好，但是它可以直接把操作結果映射成需要的對象，只需要建立對應的數據對象DTO就行，并且多表關聯查詢、復雜條件查詢都可以寫SQL解決，最重要的是SQL和邏輯代碼分析，維護也很方便，SQL優化交給專業的DBA就行，再次好用到起飛。

突然有一天，公司強制要求數據庫從oracle換成MySQL，發現Mybatis因為都是寫的純SQL，原來的SQL語法是oracle的，現在都要改，太依賴數據庫了，不便于換數據源。這時想起了不依賴數據源的JPA。

總結一下個人看法：

JPA使用完全面向對象的的設計思想，一個表就是一個對象，所有的操作直接操作對象就行，方便、快捷，也不需要關注底層數據源問題，但是表之間的關系復雜了、查詢復雜了，這樣的操作不是它的強項。

Mybatis是半面向對象、半面向SQL，SQL與邏輯代碼分離，查詢結果映射成對象，所有操作上層是對象，下層用SQL，數據查詢優化上更加實用，因為是寫原生SQL，所以換數據源可能麻煩。

還是業內的那句老話，沒有絕對“銀彈”，只有適合當前業務發展需要的技術。