澳门新葡亰平台游戏网站JPA

澳门新葡亰平台游戏网站 2

本文由码农网 –
孙腾浩原创翻译,转载请看清文末的转载要求,欢迎参与我们的付费投稿计划!

当Java 1.5引入注解,企业开发者对简化EJB和其他企业产品开发抱有很大期望。

JPA全称Java Persistence API.JPA通过JDK
5.0注解或XML描述对象-关系表的映射关系,并将运行期的实体对象持久化到数据库中。

当Java
1.5引入注解,企业开发者对简化EJB和其他企业产品开发抱有很大期望。可以看一看同一时期的一篇文章用EJB
3.0简化企业Java开发。

然而从那时起,Java企业使用注解出现一些无法预料的后果和副作用,一些甚至到今天都没有被注意到。

起源

Sun引入新的JPA ORM规范出于两个原因:其一,简化现有Java EE和Java
SE应用开发工作;其二,Sun希望整合ORM技术,实现天下归一。

JPA由EJB 3.0软件专家组开发,作为JSR-220实现的一部分。但它又不限于EJB
3.0,你可以在Web应用、甚至桌面应用中使用。JPA的宗旨是为POJO提供持久化标准规范,由此可见,经过这几年的实践探索,能够脱离容器独立运行,方便开发和测试的理念已经深入人心了。Hibernate3.2+、TopLink
10.1.3以及OpenJPA都提供了JPA的实现。

JPA的总体思想和现有Hibernate、TopLink、JDO等ORM框架大体一致。总的来说,JPA包括以下3方面的技术:

ORM映射元数据

JPA支持XML和JDK5.0注解两种元数据的形式,元数据描述对象和表之间的映射关系,框架据此将实体对象持久化到数据库表中;

API

用来操作实体对象,执行CRUD操作,框架在后台替在我们完成所有的事情,开发者从繁琐的JDBC和SQL代码中解脱出来。

查询语言

这是持久化操作中很重要的一个方面,通过面向对象而非面向数据库的查询语言查询数据,避免程序的SQL语句紧密耦合。

 

然而从那时起,Java企业使用注解出现一些无法预料的后果和副作用,一些甚至到今天都没有被注意到。幸运的是,并非所有的副作用都没有被注意到,来看一些例子,在StackOverflow标题为“Why
Java
Annotations?”有很多有价值的评论,“Are
Annotations
Bad?”这篇文章有很棒的观点,还有“Magics
Is
Evil”,“Annotations…Good,
Bad or Worse?”。

澳门新葡亰平台游戏网站 1

优势

澳门新葡亰平台游戏网站 2

并非所有的注解都相同

标准化

JPA 是 JCP 组织发布的 Java EE 标准之一,因此任何声称符合 JPA
标准的框架都遵循同样的架构,提供相同的访问API,这保证了基于JPA开发的企业应用能够经过少量的修改就能够在不同的JPA框架下运行。

容器级特性的支持

JPA框架中支持大数据集、事务、并发等容器级事务,这使得 JPA
超越了简单持久化框架的局限,在企业应用发挥更大的作用。

 

并非所有的注解都相同

尽管上面许多讨论都包含有价值的观点,但并不是所有注解都是相同的。

这里有两类注解,区别在于他们是否在运行期影响程序。首先,说一下无害的一类,它们并不会在运行期对代码产生任何影响;另一种是有害的一类,它们会修改运行期行为。无害的注解包括@Deprecated,
@Override, @SuppressWarnings, 等等。有害的注解包括@Entity, @Table,
@PostConstruct, @ApplicationScoped,等等。

在无害的注解中存在一小部分注解,它们非常实用。有一些提供在编译期间(静态检查)捕获错误或提供安全保障。一些实用的注解包括:@Override,
@NonNull/@Nullable 来自(Checker
Framework), 等等。

尽管上面许多讨论都包含有价值的观点,但并不是所有注解都是相同的。

简单方便

JPA的主要目标之一就是提供更加简单的编程模型:在JPA框架下创建实体和创建Java
类一样简单,没有任何的约束和限制,只需要使用
javax.persistence.Entity进行注释,JPA的框架和接口也都非常简单,没有太多特别的规则和设计模式的要求,开发者可以很容易的掌握。JPA基于非侵入式原则设计,因此可以很容易的和其它框架或者容器集成。

 

为什么有害的注解不好?

我们定义了一些有害的注解,为什么要避免使用它们呢?

想象一个标准的Java
Data类拥有@PostConstruct方法。这个注解表示所标注的方法应该在对象创建好之后被调用。这个功能并不是由JVM处理,所以Date类隐式获取未知的框架和容器,而自身语义上并没有做任何事情。如果这些代码并不运行在任何容器中,而只是运行在JVM中呢?这个注解大大降低了这个类的重用性。另外对于任何使用Date的地方进行单元测试就变成了噩梦,因为你必须确保每次都正确绑定post-construction,要模拟一个兼容的容器。这就有点可笑了,一个Date类需要一个容器来运行,但这确实是有害的注解对类、方法和参数的影响。

无可否认,业务逻辑往往复杂,需要更多依赖和关系,而不仅仅是一个简单的Date类。然而没有理由在一个类中显式或隐式地添加不必要的依赖或约束,有害的注解就是:依赖和约束。

这里有两类注解,区别在于他们是否在运行期影响程序。首先,说一下无害的一类,它们并不会在运行期对代码产生任何影响;另一种是有害的一类,它们会修改运行期行为。无害的注解包括@Deprecated,
@Override, @SuppressWarnings, 等等。有害的注解包括@Entity, @Table,
@PostConstruct, @ApplicationScoped,等等。

查询能力

JPA的查询语言是面向对象而非面向数据库的,它以面向对象的自然语法构造查询语句,可以看成是Hibernate
HQL的等价物。JPA定义了独特的JPQL(Java Persistence Query
Language),JPQL是EJB
QL的一种扩展,它是针对实体的一种查询语言,操作对象是实体,而不是关系数据库的表,而且能够支持批量更新和修改、JOIN、GROUP
BY、HAVING 等通常只有 SQL
才能够提供的高级查询特性,甚至还能够支持子查询。

 

企业陷阱

不幸的是有害的声明在Java Enterprise
5大规模合法化。为了更正早期企业API的易用性问题,注解用来隐藏系统中冗余的和难用的部分。新的JEE
5被称赞为”轻量级”和”简单”,表面上看起来是这样。但是一个微小的,同时也是至关重要的误用蔓延开来。

@Stateless
public class DocumentRepository {
   public Document getDocument(String title) {
      ...
   }
   ...
}

如果想要获取一个Stateless
EJB,“只需要”在类上声明@Stateless注解。确实,编写这个类只需要只一点动作,但是请注意这个类中有害的注解绑定了几百页的说明文档,而且只能在百万字节的应用服务器(Application
Server)上运行。这又怎么能称的上是”轻量级”呢。所以,这个注解仅仅是真正需要编写的Java代码的占位符而已,代码仍需要以某种形式存在。现在只不过是隐藏在注解之下。

不幸的是,这种变通方案称为一种模式,现在有害的注解广泛分布:JPA, CDI,
Common Annotations, JAXB 等等。

在无害的注解中存在一小部分注解,它们非常实用。有一些提供在编译期间(静态检查)捕获错误或提供安全保障。一些实用的注解包括:@Override,
@NonNull/@Nullable 来自(Checker Framework), 等等。

高级特性

JPA
中能够支持面向对象的高级特性,如类之间的继承、多态和类之间的复杂关系,这样的支持能够让开发者最大限度的使用面向对象的模型设计企业应用,而不需要自行处理这些特性在关系数据库的持久化。

 

有害的注解有时会出现在错误的地点

因为注解通常作为开发环境,有时有害的注解被当做单一职责原则(Single
Responsibility Principle)或关注点分离(Separation of
Concerns)的最佳实践。

让我们来考虑一下下面这个CDI例子:

@ApplicationScoped
public class DocumentFormatter {
   ...
}

上面的注解描述这个类应该是一个CDI
Bean,意味着它应该只能由CDI实例化,并确保每个应用中只有一个实例。

这些信息并不属于这个类。这个服务在功能上(无论什么方式)并不会对它在当前应用中的作用产生影响。这里有两个明显的关注点。

一个JPA的简单例子:

@Entity
@Table("PERSON")
public class Person {
   ...
}

问题在于这种类往往是”领域对象(domain
objects)”,它们直接将领域模型持久化。更糟的是,数据传送对象(DTO)用来在对象之间传送数据,使得整个构造变得脆弱,因为对象间耦合过于紧密。不管怎样,这是一种错误的方式。

所有的这些附加的功能和(或)信息应该从这些类中分离出来,但是它们却悄悄混在一起,因为它们”只不过”是注解。

为什么有害的注解不好?

供应商

JPA
的目标之一是制定一个可以由很多供应商实现的API,并且开发人员可以编码来实现该API,而不是使用私有供应商特有的API。因此开发人员只需使用供应商特有的API来获得JPA规范没有解决但应用程序中需要的功能。尽可能地使用JPA
API,但是当需要供应商公开但是规范中没有提供的功能时,则使用供应商特有的API。

 

有害的注解有时蔓延

注解有时会传染其他对象。回顾上面那个CDI
Bean。每个使用它的对象,每个依赖它的对象现在都拥有一个CDI注解,否则依赖关系树就不会构建成功。

@Entity注解也一样。因为对象之间的关系,其他对象也通过注解持久化,很快所有的持久化对象都会有这个注解。我们无法使用原生的第三方对象(除非序列化或包装它们),我们无法使用其他持久化机制(比如用NoSQL
DB存放对象)。

这些注解使得这些对象无法复用。它们只能在一个严格的、受控制的、不透明的环境中使用,不能和任何东西整合。

我们定义了一些有害的注解,为什么要避免使用它们呢?

Hibernate

JPA是需要Provider来实现其功能的,Hibernate就是JPA
Provider中很强的一个,应该说无人能出其右。从功能上来说,JPA就是Hibernate功能的一个子集。Hibernate
从3.2开始,就开始兼容JPA。Hibernate3.2获得了Sun TCK的JPA(Java
Persistence API) 兼容认证。

只要熟悉Hibernate或者其他ORM框架,在使用JPA时会发现其实非常容易上手。例如实体对象的状态,在Hibernate有自由、持久、游离三种,JPA里有new,managed,detached,removed,明眼人一看就知道,这些状态都是一一对应的。再如flush方法,都是对应的,而其他的再如说Query
query =
manager.createQuery(sql),它在Hibernate里写法上是session,而在JPA中变成了manager,所以从Hibernate到JPA的代价应该是非常小的

同样,JDO,也开始兼容JPA。在ORM的领域中,看来JPA已经是王道,规范就是规范。在各大厂商的支持下,JPA的使用开始变得广泛。

 

有什么替代品?

是XML吗?当然不是,至少对于上面的例子来说不是。

Spring框架使用配置来管理对象,因此可以用XML当做配置文件。然而,是否某个依赖需要在运行期改变,而不通过重新编译?如果不需要,那么很难说配置应该用另一门语言来表示,尤其重构困难、测试困难、管理需要特殊工具。

真正的替代品当然是好的Java代码,正确封装并解耦的。是的,用代码来管理对象,尽管有时被当做样板(boilerplate),但并不算糟糕。它带来一些好处,比如让代码可读、可调试、可重构。只有那些长片的、复杂的、冗余的样板是糟糕的,比如“关于EJB
2.0”。但是解决方案并不是摆脱所有的样板或用另一种语言隐藏样板,而是简单干净的架构,直接而不多余的信息,简单并合适的方式来面向对象。

这也适用于JPA、Spring和其他东西。误用注解来表示功能会发生Stcakoverflow上这个问题“Arguments
Against
Annotations”,为什么不用已有的工具呢:比如Java语言本身和编译器,来解决这类问题,面向对象和软件最佳实践。

想象一个标准的Java
Data类拥有@PostConstruct方法。这个注解表示所标注的方法应该在对象创建好之后被调用。这个功能并不是由JVM处理,所以Date类隐式获取未知的框架和容器,而自身语义上并没有做任何事情。如果这些代码并不运行在任何容器中,而只是运行在JVM中呢?这个注解大大降低了这个类的重用性。另外对于任何使用Date的地方进行单元测试就变成了噩梦,因为你必须确保每次都正确绑定post-construction,要模拟一个兼容的容器。这就有点可笑了,一个Date类需要一个容器来运行,但这确实是有害的注解对类、方法和参数的影响。

Spring

Spring + Hibernate 常常被称为 Java Web 应用人气最旺的框架组合。而在 JCP
通过的 Web Beans JSR ,却欲将JSF + EJB + JPA 、来自 JBoss Seam(Spring
除外)的一些组件和EJB 3(能够提供有基本拦截和依赖注入功能的简化 Session
Bean框架)的一个 Web 组合进行标准化。Spring 2.0 为 JPA 提供了完整的
EJB容器契约,允许 JPA在任何环境内可以在 Spring 管理的服务层使用(包括
Spring 的所有DI 和 AOP增强)。同时,关于下一个Web应用组合会是
EJB、Spring + Hibernate 还是 Spring + JPA 的论战,早已充斥于耳。

在Spring
2.0.1中,正式提供对JPA的支持,这也促成了JPA的发展,要知道JPA的好处在于可以分离于容器运行,变得更加的简洁。

 

总结

如果注解在代码运行期加上了额外功能和约束,那它是有害的。这很糟糕,因为它隐藏了类或方法的切面,使之难懂、难复用、难重构、难测试。

不幸的是Java
Enterprise不理睬Java开发者社区中发对注解的声音。所以企业级Java和其他”官方”框架更不可能重视这类问题。

至少我们可以持续关注有害的注解,如果可能尽量避免使用,编写新的框架和软件替换掉注解,不会出现有害注解所带来的问题。

无可否认,业务逻辑往往复杂,需要更多依赖和关系,而不仅仅是一个简单的Date类。然而没有理由在一个类中显式或隐式地添加不必要的依赖或约束,有害的注解就是:依赖和约束。

OpenJPA

OpenJPA 是 Apache 组织提供的开源项目,它实现了 EJB 3.0 中的 JPA
标准,为开发者提供功能强大、使用简单的持久化数据管理框架。OpenJPA
封装了和关系型数据库交互的操作,让开发者把注意力集中在编写业务逻辑上。OpenJPA
可以作为独立的持久层框架发挥作用,也可以轻松的与其它 Java EE
应用框架或者符合 EJB 3.0 标准的容器集成。

支持的实现包括Toplink、Hibernate
Entitymanager等。TopLink以前需要收费,如今开源了。OpenJPA虽然免费,但功能、性能、普及性等方面更加需要加大力度。

对于EJB来说,实体Bean一直是被批评的对象,由于其太复杂和庞大。JPA的出现,很大程度的分离了复杂性。这让EJB的推广也变得容易。

总而言之,JPA规范主要关注的仅是API的行为方面,而由各种实现完成大多数性能有关的调优。尽管如此,所有可靠的实现都应该拥有某种数据缓存,以作为选择。但愿不久的将来,JPA能成为真正的标准。

 

对于正在学习Java但不知道学习路线,不知道学习方法,不知道该如何找到工作的朋友,我还是要推荐下我自己建的Java学习君羊:479121291,首先你要是学Java的,其次不管你是小白还是大牛,小编都挺欢迎,群里每天都会分享Java相关干货,包括我最近整理出的一份适合2018年自学的最新Java资料,都送给大家,欢迎初学和进阶中的小伙伴。

小结

EJB 3.0和JPA 毫无疑问将是Java EE
5的主要卖点。在某些领域中,它们给Java社区带来了竞争优势,并使Java
在其他领域与竞争对手不分伯仲(因为,不可否认,某些领域尚不存在基于标准的方法)。

过去数年来,Spring Framework一直是EJB在企业领域的主要竞争对手。EJB
3.0规范解决了很多促进Spring兴起的问题。随着它的出现,EJB3.0毫无疑问比Spring提供了更好的开发体验——最引人注目的优势是它不需要配置文件。

JPA提供一种标准的OR映射解决方案,该解决方案完全集成到EJB3.0兼容的容器中。JPA的前辈将会继续稳定发展,但是业务应用程序中的
raw 使用将可能会减少。实现 JPA
兼容的实体管理器似乎很可能是此类技术的发展方向。

Java EE系列规范的较大问题与JPA没有任何关系。Java EE 系列规范的问题涉及到
Web和EJB容器之间的集成。Spring在此领域仍然具有主要竞争优势。JBoss的Seam项目尝试使用自定义的方法来解决这一问题。Caucho
Resin应用服务器试图扩展容器边界并支持在Web容器中使用@EJB注释。我们希望Java
EE 5.1将解决层集成的问题,为我们提供一个全面而标准的依赖性注入方法。

在不久的将来,Oracle可能会将JPA作为一个单独的JSR对待,同时JPA还可能作为Java
SE的一部分。不过这些都不太重要,重要的是,我们已经可以在脱离容器的情况下、在Java
SE应用中使用JPA了。

JPA已经作为一项对象持久化的标准,不但可以获得Java
EE应用服务器的支持,还可以直接在Java
SE中使用。开发者将无需在现有多种ORM框架中艰难地选择,按照Sun的预想,现有ORM框架头顶的光环将渐渐暗淡,不再具有以往的吸引力。

企业陷阱

不幸的是有害的声明在Java Enterprise
5大规模合法化。为了更正早期企业API的易用性问题,注解用来隐藏系统中冗余的和难用的部分。新的JEE
5被称赞为”轻量级”和”简单”,表面上看起来是这样。但是一个微小的,同时也是至关重要的误用蔓延开来。

@StatelesspublicclassDocumentRepository{publicDocumentgetDocument(String
title){      …  }  …}

如果想要获取一个Stateless
EJB,“只需要”在类上声明@Stateless注解。确实,编写这个类只需要只一点动作,但是请注意这个类中有害的注解绑定了几百页的说明文档,而且只能在百万字节的应用服务器(Application
Server)上运行。这又怎么能称的上是”轻量级”呢。所以,这个注解仅仅是真正需要编写的Java代码的占位符而已,代码仍需要以某种形式存在。现在只不过是隐藏在注解之下。

不幸的是,这种变通方案称为一种模式,现在有害的注解广泛分布:JPA, CDI,
Common Annotations, JAXB 等等。

有害的注解有时会出现在错误的地点

因为注解通常作为开发环境,有时有害的注解被当做单一职责原则(Single
Responsibility Principle)或关注点分离(Separation of
Concerns)的最佳实践。

让我们来考虑一下下面这个CDI例子:

@ApplicationScopedpublicclassDocumentFormatter{  …}

上面的注解描述这个类应该是一个CDI
Bean,意味着它应该只能由CDI实例化,并确保每个应用中只有一个实例。

这些信息并不属于这个类。这个服务在功能上(无论什么方式)并不会对它在当前应用中的作用产生影响。这里有两个明显的关注点。

一个JPA的简单例子:

@Entity@Table(“PERSON”)publicclassPerson{  …}

问题在于这种类往往是”领域对象(domain
objects)”,它们直接将领域模型持久化。更糟的是,数据传送对象(DTO)用来在对象之间传送数据,使得整个构造变得脆弱,因为对象间耦合过于紧密。不管怎样,这是一种错误的方式。

所有的这些附加的功能和(或)信息应该从这些类中分离出来,但是它们却悄悄混在一起,因为它们”只不过”是注解。

有害的注解有时蔓延

注解有时会传染其他对象。回顾上面那个CDI
Bean。每个使用它的对象,每个依赖它的对象现在都拥有一个CDI注解,否则依赖关系树就不会构建成功。

@Entity注解也一样。因为对象之间的关系,其他对象也通过注解持久化,很快所有的持久化对象都会有这个注解。我们无法使用原生的第三方对象(除非序列化或包装它们),我们无法使用其他持久化机制(比如用NoSQL
DB存放对象)。

这些注解使得这些对象无法复用。它们只能在一个严格的、受控制的、不透明的环境中使用,不能和任何东西整合。

有什么替代品?

是XML吗?当然不是,至少对于上面的例子来说不是。

Spring框架使用配置来管理对象,因此可以用XML当做配置文件。然而,是否某个依赖需要在运行期改变,而不通过重新编译?如果不需要,那么很难说配置应该用另一门语言来表示,尤其重构困难、测试困难、管理需要特殊工具。

真正的替代品当然是好的Java代码,正确封装并解耦的。是的,用代码来管理对象,尽管有时被当做样板(boilerplate),但并不算糟糕。它带来一些好处,比如让代码可读、可调试、可重构。只有那些长片的、复杂的、冗余的样板是糟糕的,比如“关于EJB
2.0”。但是解决方案并不是摆脱所有的样板或用另一种语言隐藏样板,而是简单干净的架构,直接而不多余的信息,简单并合适的方式来面向对象。

这也适用于JPA、Spring和其他东西。误用注解来表示功能会发生Stcakoverflow上这个问题“Arguments
Against
Annotations”,为什么不用已有的工具呢:比如Java语言本身和编译器,来解决这类问题,面向对象和软件最佳实践。

总结

如果注解在代码运行期加上了额外功能和约束,那它是有害的。这很糟糕,因为它隐藏了类或方法的切面,使之难懂、难复用、难重构、难测试。

不幸的是Java
Enterprise不理睬Java开发者社区中发对注解的声音。所以企业级Java和其他”官方”框架更不可能重视这类问题。

至少我们可以持续关注有害的注解,如果可能尽量避免使用,编写新的框架和软件替换掉注解,不会出现有害注解所带来的问题。

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图