當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

1.0jpa 2.0_JPA 2.1如何成为新的EJB 2.0

發布時間：2023/12/3 编程问答 40 豆豆

生活随笔收集整理的這篇文章主要介紹了 1.0jpa 2.0_JPA 2.1如何成为新的EJB 2.0 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

1.0jpa 2.0

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

了解有關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")})})

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

我特別喜歡Thorben隨后寫道：

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

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

b）應用映射

在某些Java類型上靜態定義了映射后，您就可以通過應用上述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類型并顯式轉換，因為沒有可驗證的類型信息真正附加到任何東西上。

“復雜”的定義

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

問題在這里：

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

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

@Override
@Deprecated （盡管，comment屬性會很漂亮）
@FunctionalInterface

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

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

閱讀以上內容時，我的內心深處很強烈。您還記得以下內容嗎？

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

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

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

這是使用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數據轉換為圖表

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

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

在前面的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
現在，我們有了Java中的并行Universe類型系統
該并行Universe類型系統完全沒有用，因為編譯器無法對其進行自省
Java SE 8引入了函數式編程和許多類型推斷
Java SE 9-10將引入更多很棒的語言功能
現在很清楚，配置（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