共計 3286 個字符，預計需要花費 9 分鐘才能閱讀完成。

本篇內容主要講解“AbstractEntity 需要準備的有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“AbstractEntity 需要準備的有哪些”吧!

關系型數據庫其實很討人厭，尤其是在你使用數據庫驅動的開發模式時。需要首先把表給創建好了，然后再使用代碼生成器反向生成一堆幾乎無法可讀的代碼。當字段有變更的時候，又是一番折騰。

這其中的典型，就是 MyBatis，所以催生了更加簡潔的 MyBatis Plus。

了解到一些大廠(阿里、騰訊、抖音等)，JPA 的使用也越來越廣泛了，包括我們公司，這是把合適的工具放到了合適的地方。如果想要快速開發，JPA 無疑是一個比較好的選擇。你無需關注數據庫表的結構，使用代碼驅動即可完成工作，管它后面是 MySQL 還是 Oracle。JPA 把數據庫相關的知識給弱化了，讓你專注于業務開發。

我個人曾是非常排斥 JPA 這種弱化 SQL 的工具的，這源于對早起 Hibernate 版本的錯誤認識。但嘗試過 mybatis、spring-data-jdbc、jooq 后，發現這個東西是真的香! 一個遲到的贊，送給 JPA。

這對一些管理系統來說，非常合適。因為性能并不是這些系統主要的痛點，業務復雜性才是。

本文將介紹一個簡單的實體類，需要準備哪些基本字段。這些字段，又是如何在代碼中被使用的。

1. 基本字段介紹

首先看一下我們的基礎定義類。

代碼不多，信息卻不少。

下面來一行行解析。

@Data

Data 注解是屬于 lombok 類的，lombok 是地球人都知道的代碼簡化工具，提供了非常多的注解。如果你不想記憶太多的注解，直接加上一個 Data，是最偷懶的選擇。

@MappedSuperclass

這個注解是 JPA 的，用來標識父類。標注為 @MappedSuperclass 的類將不是一個完整的實體類，不會映射到數據庫表，但是它的屬性都將映射到子類的數據庫字段中。放在這里再合適不過了。

@EntityListeners(AuditingEntityListener.class)

開啟自動審計功能，這個和下面的兩個日期字段是相互配合的，我們稍后介紹。

@JsonIgnoreProperties(value = { hibernateLazyInitializer ,  handler}) // 直接使用 bean 時，避免 json 序列號失敗

有時候，我們想要再 controller 層直接使用 JPA 的實體。但 JPA 內部其實是有很多附加變量的，比如 hibernateLazyInitializer。

為了讓實體在 json 序列化的時候能夠正常進行，需要忽略這兩個字段。所以這個注解，是屬于 jackson json 的。

2.   自定義 ID 生成器

JPA 其實提供了非常多的 ID 生成策略。不過，在互聯網應用下，應用較多的還是雪花算法，因為它有著良好的擴展性，在數據遷移的時候也不會有很多沖突。

為了指定雪花算法，我們需要下面幾行代碼。

static final String ID_GEN =  cn.xjjdog.bcmall.utils.db.DistributedId  @Id @GenericGenerator(name =  IdGen , strategy = ID_GEN) @GeneratedValue(generator =  IdGen)

其中的一個關鍵，就是使用我們名稱叫做 IdGen 的 ID 生成器。這里的代碼，是有一點小遺憾的。由于 JVM 類加載的緣故，我們無法在注解中直接使用類的名稱(*.class.getName())   來獲取它的包路徑，只能作為字符串寫死在這里。

下面我們就來看一下這個 ID 生成器的處理。

public class DistributedId implements IdentifierGenerator { @Override public Serializable generate(SharedSessionContractImplementor sharedSessionContractImplementor, Object obj) throws HibernateException { if (obj == null) throw new HibernateException(new NullPointerException()) ; if ((((AbstractEntity) obj).getId()) == null) { return String.valueOf(Snowflake.createId()); } else { return ((AbstractEntity) obj).getId(); } } }

代碼如上。在直接使用之前，我們還做了一點小處理。當我們判斷實體的 ID 為空的時候，才使用雪花算法構造一個新的 ID; 否則使用實體原來設置好的 ID，保持不變。

為什么這樣做? 因為這是有需求的。像訂單這種業務，你需要先生成一個訂單號，然后再更新一些數據庫信息，發布一些消息等; 而不是在保存動作出發的時候才生成一個。

如果你不做上面代碼的處理。JPA 將每次保存的時候都自動生成一個，覆蓋了你原有的。我就在這里吃過虧，通過 debug 代碼才進行的修復。

3.   自動填充字段

上面說到 createdDate 和 lastModifiedDate 兩個字段，其實在使用的時候，是不需要手動去設值的。這兩個值，將通過審計功能自動完成。

@EntityListeners(AuditingEntityListener.class)

當然，我們還要用特有的注解，來標識這兩個字段。

/** *  創建時間  */ @CreatedDate private Date createdDate; /** *  更新時間  */ @LastModifiedDate private Date lastModifiedDate;

最后，不要忘了在全局配置中通過 Config 開啟這個功能。

@Configuration @EnableJpaAuditing public class JpaConfig { }

當然，審計是不能沒有用戶的。所以這個系列還有 @CreatedBy 注解，用來標注是誰創建的。你需要在代碼中組裝它們，比如下面的代碼，就是從 Spring  Sercurity 中獲取用戶信息。

@Configuration @Slf4j public class UserAuditor implements AuditorAware String  { @Override public Optional String  getCurrentAuditor() { UserDetails user; try { user = (UserDetails) SecurityContextHolder.getContext().getAuthentication().getPrincipal(); return Optional.ofNullable(user.getUsername()); }catch (Exception e){ return Optional.empty(); } } }

4. End

JPA 寫管理系統，真的是神器。當你不需要考慮極限的代碼效率時，是一個非常好的選擇。再看看最近的 MyBatis 版本，包括 MyBatis  Plus 設計，很多東西已經和 JPA 越來越像了。因為在設計上來說，JPA 是最接近面向對象編程的思想的。

B 端復雜業務的技術棧，并不需要和 C 端的技術棧相雷同。JPA 顯然通過極少的代碼和約定，就能把事情搞定，讓開發者真正的把重點關注到業務開發上來。后面的文章，我們還會用到 MyBatis 和 MyBatis  Plus，到時候，我們再詳細分析它們使用的場景。

到此，相信大家對“AbstractEntity 需要準備的有哪些”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！