em.getReference的使用

JPA Best Practices

分离ORM MetaData
JPA Metadata有两大类，一类是描述Entity之间的关系，而另一类是描述Entity到数据库的映射关系。

众所周知，应用JPA的Metadata有两个途径：Annotation和XML。在这里我不对两者的优劣进行比较。我们着眼的是JPA，JPA在Spec中强调的一点是可移植性的应用，这就意味着使用JPA的应用程序要有比较强的移植能力。如何达到这一点呢？

Patrick的建议是用Annotation描述Entity关系，用XML描述数据库映射。好处很明显，即通过不同的XML增强了应用程序的可移植性。也没有丢失Annnotation的自释性，让开发者在开发过程中一目了然。

不过，我想补充的是，Annotation相对于XML效验的限制性相对小，所以灵活性会更大。例子是尝试在Embedded Object里面用GeneratedValue，这个在XML里面是无法完成的，Annotation是支持的，至少我常用的OpenJPA也能够在功能上完全支持。

 

使用em.getReference减少不必要的操作
Patrick提到这个方法可以在某些特定的场景下减少不必要的数据库操作，以达到提高性能的目的。

首先看getReference做了什么，在JavaDoc中定义了"获取一个实例，其状态是延迟读取的"。我一开始也没有注意到这个方法，因为我没有想到什么地方可以用这个。Patrick提供了一些很好的例子：

em.remove(em.getReference(Entity.class, EntityId))
em.lock(em.getRefenece(Entity.class, EntityId), LockMode)
相比较传统的em.find，其作用不言而喻。em.getReference不会真正去做数据库的select，而是假装把Entity的实例给你了。等你真正去做相应操作的时候由JPA Implementation决定如何去读。就上面的例子来说，OpenJPA就不会去做Select了。相比较SQL就会看到：

操作 SQL
em.remove(em.getReference(Entity.class, EntityId)) delete from Entity where id = EntityId.
em.remove(em.find(Entity.class, EntityId)) select * from Entity where id = EntityId
delete from Entity where id = EntityId.

而SELECT对于remove来说这是不怎么必要，当Entity比较大的时候相当明显。

应当注意到getReference也不能乱用，因为潜在的EntityNotFoundException会在第一次访问的时候抛出来，这就会增加系统的复杂性，有时候得不偿失。另外对于将用于Detached状态的Instance，getReference也不适用。

 

使用JPA乐观锁定
在JPA中定义了乐观锁定的规则，也就是用@Version。JPA中没有定义悲观锁定的要求，JPA的实现是可以自己实现的。

乐观锁定可能说所有的ORM都是"居家旅行，必备良药"，所以我也不在这里罗嗦了，总之好处相当之多。

 

使用Entity Facade
这个我在关于对现有CMP进行的JPA升迁 中描述过，通过Facade模式减少了业务代码中对于JPA代码的依赖。

 

NamedQuery的命名规范
这是因为JPA的对于NamedQuery的界定造成的，在单一Persistence Unit当中，NamedQuery是全局性的。如果两个Entity同时使用了相同的名字会产生冲突，而具体会用到哪个将由JPA实现来决定，这样就会产生非所期待的结果。强烈建议所有的NamedQuery同一命名规范，我自己常用的是EntityName.NamedQuery，这样把重名的风险降低到Entity一个级别，而且要求定义在Class里面，不允许动态创建NamedQuery。

 

我将在JPA Best Practices[2]中介绍在设计和代码中的一些Bast Practices。