昨天Java Persistence API (JPA)是一个热点话题，至少有三场关于该主题的演讲。前两场演讲是由Mike Keith (Oracle)所做的Using the Java Persistence API以及Patrick Linskey (BEA)所做的Enterprise Development with the Java Persistence API。接下来是Rod Johnson和Costin Leau的演讲Spring and JPA。
BEA和Oracle同台宣扬JPA说明了JPA的一个优势——多供应商支持。
在Patrick的演讲中，我了解到了在EJB 3中使用属性访问（而不是字段访问）的不利之处。例如，假设在EJB中使用如下代码：
@OneToMany public Carrier getCarrier() {return carrier;}
public void setCarrier(Carrier c) {
if (!c.servesAirport(gate.getAirport())
throw new IllegalStateException('...')
else
carrier = c;
}
这是有意义的业务逻辑。但是如果该逻辑是属性访问，则现在该逻辑也可用于查询中。提供者将必须在查询处理过程中调用setCarrier()。应答。可以使用属性访问方法绕过这个问题。
Rod和Costin对于为什么在Spring中提供JPA支持给出了一些很好的解释，并说明该支持以后将进一步增强。他们的目标包括：在配置方面进一步简化JPA的使用，鼓励最佳实践，使JPA更易于移植，以及提供测试支持。
我觉得“更易于移植”这一条有点奇怪，但是事实是，比如说，所有的供应商都提供生成DDL的方法，但是却没有一种标准方法。在登录和公开底层数据源方面也是如此。Spring将统一各家供应商的配置。 下面是一个例子：
<jpa:entityManagerFactory
persistence-unit-name="myPU">
<jpa:vendor generate-ddl="true" >
<jpa:provider name="toplink" />
</jpa:vendor>
</jpa:entityManagerFactory>
现在只需更改一行代码就可以转换供应商。
如果您使用过他们的其他OR支持的话，那么您完全可以预料到其JPA支持中的编程模型是什么样的：您拥有传统的模板方法(JpaTemplate)，还可直接使用Spring/JPA注入——例如——实体管理器。似乎使用这种方法而不使用那种方法并没有什么实际的差别。我认为如果要迁移到JPA，最好使用模板方法。模板方法有一个优点：它允许用户利用Spring的异常解释支持。不过，似乎Spring 2.0引入了几个自己的注释来解决这个问题。现在Spring 2.0中有一个@Repository注释，它将确保所有的异常都被解释。例如：
@Repository
public class Foo {
@PersistenceContext
private EntityManager em;
// exceptions will be automatically translated
public Collection doSmth(Object smvalue) {
...
}
要使用储存库功能，使用上述的@Repository标签，然后在上下文中包括一个PersistenceExceptionTranslationPostProcessor。
Rod还提到了他们对JPA的测试支持。无疑，AbstractJpaTests实现非常有趣，但是我没有时间听了。
展望未来，他们谈到可能会提供JPA的API扩展（比如一个条件API)。但这并不是一个承诺。
技术标签：bea、dev2dev、java、java persistence api、spring framework、springone
评论
- 非常有趣的文章。Spring对不同的JPA供应商所做的工作正与数据库连接池对不同的数据库所做的工作类似。人们往往更喜欢使用高级的抽象而不是低级的API。
发表人：mychen，2006年6月16日，08:36 AM
