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

1.0jpa 2.0