怎么同時使用JPA和Mybatis

這篇文章主要講解了“怎么同時使用JPA和Mybatis”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么同時使用JPA和Mybatis”吧！

建模

@Entity @Table(name = "t_order") public class Order {      @Id   private String oid;      @Embedded   private CustomerVo customer;      @OneToMany(cascade = {CascadeType.ALL}, orphanRemoval = true, fetch = FetchType.LAZY, mappedBy = "order")   private List<OrderItem> orderItems; }

JPA 最大的特點是 sqlless，如上述的實體定義，便將數據庫的表和 Java 中的類型關聯起來了，JPA 可以做到根據 @Entity  注解，自動創建表結構;基于這個實體實現的 Repository 接口，又使得 JPA 用戶可以很方便地實現數據的 CRUD。所以，使用 JPA  的項目，人們很少會提到”數據庫設計“，人們更關心的是領域建模，而不是數據建模。

<generatorConfiguration>     <context id="my" targetRuntime="MyBatis3">              <jdbcConnection driverClass="com.mysql.jdbc.Driver" connectionURL=""            userId="" password=""/>        <javaModelGenerator targetPackage="" targetProject="" />        <sqlMapGenerator targetPackage="" targetProject="" />        <javaClientGenerator targetPackage="moe.cnkirito.demo.mapper" />              <table tableName="t_order" domainObjectName="Order" />       </context> </generatorConfiguration>

Mybatis 用戶更多使用的是逆向工程，例如 mybatis-generator 插件根據如上的 xml 配置，便可以直接將表結構轉譯成 mapper  文件和實體文件。

code first 和 table first  從結果來看是沒有區別的，差異的是過程，所以設計良好的系統，并不會僅僅因為這個差異而高下立判，但從指導性來看，無疑設計系統時，更應該考慮的是實體和實體，實體和值對象的關聯，領域邊界的劃分，而不是首先著眼于數據庫表結構的設計。

建模角度來看，JPA 的領域建模思想更勝一籌。

數據更新

聊數據庫自然離不開 CRUD，先來看增刪改這些數據更新操作，來看看兩個框架一般的習慣是什么。

JPA 推崇的數據更新只有一種范式，分成三步：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 先 findOne 映射成實體

3. 內存內修改實體

4. 實體整體 save

你可能會反駁我說，@Query 也存在 nativeQuery 和 JPQL 的用法，但這并不是主流用法。JPA 特別強調”整體  save“的思想，這與領域驅動設計所強調的有狀態密不可分，即其認為，修改不應該是針對于某一個字段：”update table set a=b where  colomonA=xx“ ，而應該反映成實體的變化，save 則代表了實體狀態最終的持久化。

先 find 后 save 顯然也適用于 Mybatis，而 Mybatis 的靈活性，使得其數據更新方式更加地百花齊放。路人甲可以認為 JPA  墨守成規不懂變通，認為 Mybatis 不羈放縱愛自由;路人乙也可以認為 JPA 格式規范易維護，Mybatis 不成方圓。這點不多加評判，留后人說。

從個人習慣來說，我還是偏愛先 find 后整體 save 這種習慣的，不是說這是 JPA 的專利，Mybatis 不具備;而是 JPA  的強制性，讓我有了這個習慣。

數據更新角度來看，JPA 強制使用 find+save，mybatis 也可以做到這一點，勝者：無。

數據查詢

JPA 提供的查詢方式主要分為兩種

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 簡單查詢：findBy + 屬性名

3. 復雜查詢：JpaSpecificationExecutor

簡單查詢在一些簡單的業務場景下提供了非常大的便捷性，findBy + 屬性名可以自動轉譯成 sql，試問如果可以少寫代碼，有誰不愿意呢?

復雜查詢則是 JPA 為了解決復雜的查詢場景，提供的解決方案，硬是把數據庫的一些聚合函數，連接操作，轉換成了 Java 的方法，雖然做到了  sqlless，但寫出來的代碼又臭又長，也不見得有多么的易讀易維護。這算是我最不喜歡 JPA 的一個地方了，但要解決復雜查詢，又別無他法。

而 Mybatis 可以執行任意的查詢 sql，靈活性是 JPA 比不了的。數據庫小白搜索的最多的兩個問題：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 數據庫分頁怎么做

3. 條件查詢怎么做

Mybatis 都可以輕松的解決。

千萬不要否認復雜查詢：如聚合查詢、Join 查詢的場景。令一個 JPA 用戶抓狂的最簡單方式，就是給他一個復雜查詢的 case。

select a,b,c,sum(a) where a=xx and d=xx group by a,b,c;

來吧，展示。可能 JPA 的確可以完成上述 sql 的轉義，但要知道不是所有開發都是 JPA 專家，沒人關心你用 JPA  解決了多么復雜的查詢語句，更多的人關心的是，能不能下班前把這個復雜查詢搞定，早點回家。

在回到復雜數據查詢需求本身的來分析下。我們假設需求是合理的，畢竟項目的復雜性難以估計，可能有 1000 個數據查詢需求 JPA  都可以很方便的實現，但就是有那么 10 幾個復雜查詢 JPA hold 不住。這個時候你只能乖乖地去寫 sql 了，如果這個時候又出現一個條件查詢的場景，出現了  if else 意味著連 @Query 都用不了，完全退化成了 JdbcTemplate 的時代。

那為什么不使用 Mybatis 呢?Mybatis 使用者從來沒有糾結過復雜查詢，它簡直就是為之而生的。

如今很多 Mybatis 的插件，也可以幫助使用者快速的生成基礎方法，雖然仍然需要寫 sql，但是這對于開發者來說，并不是一件難事。

不要質疑高并發下，JOIN 操作和聚合函數存在的可能性，數據查詢場景下，Mybatis 完勝。

性能

本質上 ORM 框架并沒有性能的區分度，因為最終都是轉換成 sql 交給數據庫引擎去執行，ORM 層面那層性能損耗幾乎可以忽略不計。

但從實際出發，Mybatis 提供給了開發者更高的 sql 自由度，所以在一些需要 sql 調優的場景下會更加靈活。

可維護性

前面我們提到 JPA 相比 Mybatis 喪失了 sql 的自由度，凡事必有 trade  off，從另一個層面上來看，其提供了高層次的抽象，嘗試用統一的模型去解決數據層面的問題。sqlless  同時也屏蔽了數據庫的實現，屏蔽了數據庫高低版本的兼容性問題，這對可能存在的數據庫遷移以及數據庫升級提供了很大的便捷性。

同時使用兩者

其他細節我就不做分析了，相信還有很多點可以拿過來做對比，但我相信主要的點上文都應該有所提及了。進行以上維度的對比并不是我寫這篇文章的初衷，更多地是想從實際開發角度出發，為大家使用這兩個框架提供一些參考建議。

在大多數場景下，我習慣使用 JPA，例如設計領域對象時，得益于 JPA  的正向模型，我會優先考慮實體和值對象的關聯性以及領域上下文的邊界，而不用過多關注如何去設計表結構;在增刪改和簡單查詢場景下，JPA 提供的 API 已經是刻在我  DNA 里面的范式了，使用起來非常的舒服。

在復雜查詢場景下，例如

1. 包含不存在領域關聯的 join 查詢

2. 包含多個聚合函數的復雜查詢

3. 其他 JPA 較難實現的查詢

我會選擇使用 Mybatis，有點將 Mybatis 當做數據庫視圖生成器的意味。堅定不移的 JPA  擁躉者可能會質疑這些場景的存在的真實性，會質疑是不是設計的漏洞，但按照經驗來看，哪怕是短期方案，這些場景也是客觀存在的，所以聽我一言，嘗試擁抱一下  Mybatis 吧。

隨著各類存儲中間件的流行，例如  mongodb、ES，取代了數據庫的一部分地位，重新思考下，本質上都是在用專業的工具解決特定場景的問題，最終目的都是為了解放生產力。數據庫作為最古老，最基礎的存儲組件，的確承載了很多它本不應該承受的東西，那又何必讓一個工具或者一個框架成為限制我們想象力的溝壑呢?

兩個框架其實都不重，在 springboot 的加持下，引入幾行配置就可以實現兩者共存了。

感謝各位的閱讀，以上就是“怎么同時使用JPA和Mybatis”的內容了，經過本文的學習后，相信大家對怎么同時使用JPA和Mybatis這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！