美麗在于情人眼中。 “輕松”也是如此：

了解有關SQL結果集映射的更多信息，并輕松處理本機查詢結果： http : //t.co/WH4BTlClIP #JPA #Java #JavaEE

— Thorben Janssen（@ thjanssen123） 2015年4月15日

Thorben撰寫了有關JPA的非常有用的文章 ，最近他開始撰寫有關JPA 2.1的新功能的精彩系列文章。 其中：結果集映射。 您可能從CTMMC或annotatiomania.com等網站知道結果集映射。 我們可以將映射過程總結如下：

a）定義映射

@SqlResultSetMapping(name = "BookAuthorMapping",entities = {@EntityResult(entityClass = Book.class,fields = {@FieldResult(name = "id", column = "id"),@FieldResult(name = "title", column = "title"),@FieldResult(name = "author", column = "author_id"),@FieldResult(name = "version", column = "version")}),@EntityResult(entityClass = Author.class,fields = {@FieldResult(name = "id", column = "authorId"),@FieldResult(name = "firstName", column = "firstName"),@FieldResult(name = "lastName", column = "lastName"),@FieldResult(name = "version", column = "authorVersion")})})

上面的映射相當簡單。 它指定如何將數(shù)據(jù)庫列映射到實體字段和整個實體。 然后，為該映射指定一個名稱（ "BookAuthorMapping" ），然后可以在整個應用程序中重用該名稱，例如，使用本機JPA查詢。

我特別喜歡Thorben隨后寫道：

如果您不希望在實體中添加如此龐大的注釋塊，則還可以在XML文件中定義映射

…因此，我們回到了用大量XML替換大量注釋的技術–我們中的許多人都希望避免使用注釋的技術…:-)

b）應用映射

在某些Java類型上靜態(tài)定義了映射后，您就可以通過應用上述BookAuthorMapping來獲取這些實體

List<Object[]> results = this.em.createNativeQuery("SELECT b.id, b.title, b.author_id, b.version, " +" a.id as authorId, a.firstName, a.lastName, " + " a.version as authorVersion " + "FROM Book b " +"JOIN Author a ON b.author_id = a.id", "BookAuthorMapping" ).getResultList();results.stream().forEach((record) -> {Book book = (Book)record[0];Author author = (Author)record[1]; });

請注意，您仍然需要記住Book和Author類型并顯式轉換，因為沒有可驗證的類型信息真正附加到任何內容上。

“復雜”的定義

現(xiàn)在，該文章聲稱這是“復雜”映射，毫無疑問，我會同意。 如果您想通過JPA真正映射您的實體，那么只有一個簡單聯(lián)接的非常簡單的查詢已經觸發(fā)了此類注釋混亂。 一旦查詢變得復雜一點，您就不想看到Thorben的映射注釋。 記住，@ @SqlResultSetMapping是關于映射（本機！）SQL結果的，所以我們不再處于對象圖持久化領域，而是進入SQL領域 ，在該領域進行批量獲取，反規(guī)范化，聚合和其他“奇特” SQL東西為王。

問題在這里：

Java 5引入了注釋。 注釋最初打算用作“人工修飾符”，即諸如static ， final ， protected類的東西（有趣的是， 錫蘭只知道注釋，沒有修飾符 ）。 這很有道理。 Java語言設計人員可以在不破壞現(xiàn)有代碼的情況下引入新的修飾符/“關鍵字”，因為“真實”關鍵字是保留字，很難在語言中引入。 還記得enum嗎？

因此，注釋的好用例（而且很少）是：

• @Override
• @Deprecated （盡管注釋屬性會很漂亮）
• @FunctionalInterface

JPA（以及其他Java EE API以及Spring）在使用注解方面一無所知。 在我之后重復：

在Java之前或之后，沒有一種語言像Java那樣濫用注釋。

閱讀以上內容時，我的內心深處充滿了動感。 您還記得以下內容嗎？

在Java之前或之后，沒有任何一種語言比Java濫用過檢查異常。

到2020年，我們都會深表遺憾。

注釋是Java類型系統(tǒng)中的一大障礙。 它們的合理使用極為有限，而這些天我們Java Enterprise開發(fā)人員正在做的事情絕對不在“合理”的范圍內。 我們正在濫用它們來配置某些我們本該為之編寫代碼的東西。

這是使用jOOQ （或任何其他利用SQL的泛型和類型安全性的API）運行相同查詢的方式：

Book b = BOOK.as("b"); Author a = AUTHOR.as("a");DSL.using(configuration).select(b.ID, b.TITLE, b.AUTHOR_ID, b.VERSION,a.ID, a.FIRST_NAME, a.LAST_NAME,a.VERSION).from(b).join(a).on(b.AUTHOR_ID.eq(a.ID)).fetch().forEach(record -> {BookRecord book = record.into(b);AuthorRecord author = record.into(a);});

此示例結合了JPA 2.1的注釋和查詢。 有關計劃的“實體”的所有元信息已經包含在查詢中，因此也包含在fetch()方法生成的Result中。 但這并不重要，關鍵是這個lambda表達式……

record -> {BookRecord book = record.into(b);AuthorRecord author = record.into(a); }

……可以是您想要的任何東西！ 就像我們在以前的博客文章中顯示的更復雜的示例一樣：

• 不再需要ORM
• 使用jOOQ和JavaFX將SQL數(shù)據(jù)轉換為圖表

可以使用函數(shù)即時定義映射。 函數(shù)是理想的映射器，因為它們接受輸入，產生輸出并且完全無狀態(tài)。 關于Java 8中功能的最好之處在于，它們是由Java編譯器編譯的，可用于對映射進行類型檢查。 當給定的映射算法可以使用多次時，您可以將函數(shù)分配給對象，從而可以重用這些函數(shù)。

實際上，SQL SELECT子句本身就是這樣的功能。 將輸入元組/行轉換為輸出元組/行的函數(shù)，您可以使用其他表達式即時修改該函數(shù)。

在前面的JPA 2.1本機SQL語句和@SqlResultSetMapping示例中，絕對沒有任何類型可以進行類型檢查。 想象一下更改列名：

List<Object[]> results = this.em.createNativeQuery("SELECT b.id, b.title as book_title, " +" b.author_id, b.version, " +" a.id as authorId, a.firstName, a.lastName, " + " a.version as authorVersion " + "FROM Book b " +"JOIN Author a ON b.author_id = a.id", "BookAuthorMapping" ).getResultList();

您注意到差異了嗎？ b.title列已重命名為book_title 。 在SQL字符串中。 在運行時會爆炸！ 如何記住你也必須適應

@FieldResult(name = "title", column = "title")

… 成為

@FieldResult(name = "title", column = "book_title")

相反，如何記住，一旦在@FieldResult重命名了column ，就還必須檢查使用此"BookAuthorMapping"位置，并還要更改那些查詢中的列名。

@SqlResultSetMapping(name = "BookAuthorMapping",... )

注解是邪惡的

您可能同意或不同意以上某些內容。 您可能喜歡jOOQ，也可能不喜歡jOOQ ，這是完全可以的。 但是，很難不同意以下事實：

• Java 5引入了非常有用的注釋
• Java EE / Spring嚴重濫用了這些注釋來替換XML
• 現(xiàn)在，我們有了Java中的并行Universe類型系統(tǒng)
• 該并行Universe類型系統(tǒng)完全沒有用，因為編譯器無法對其進行自省
• Java SE 8引入了函數(shù)式編程和許多類型推斷
• Java SE 9-10將引入更多很棒的語言功能
• 現(xiàn)在很清楚，配置（XML或注釋）應該首先是代碼
• JPA 2.1已成為新的EJB 2.0：已過時

就像我說的。 很難不同意。 換句話說：

代碼在表達算法方面比配置好得多

我在各種會議上親自見過Thorben。 Thorben :-)這里的這句話并不是個人意思，-）您有關JPA的文章非常有趣。 如果您的讀者使用的是JPA，請查看Thorben的博客： http : //www.thoughts-on-java.org 。

同時，我很想提名Thorben贏得“ 2015年年度詮釋狂”的稱號

翻譯自: https://www.javacodegeeks.com/2015/04/how-jpa-2-1-has-become-the-new-ejb-2-0.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的JPA 2.1如何成为新的EJB 2.0的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。