Scala与Spring：强强联合

核心提示： Person实体类的具体DAO应该增加一个特定于Person实体的finder方法：traitPersonDaoextendsGenericDao[Person]{deffindByName(name:String):List[Person]//morefindershere…}我

Person实体类的具体DAO应该增加一个特定于Person实体的finder方法：

trait　PersonDao　extends　GenericDao[Person]　{　
　def　findByName(name:String):List[Person]　
　//more　finders　here…　
}　

我们需要考虑如下具体的实现细节以便利用上Scala提供的众多富有成效的特性：

关于集合：虽然底层的JPA实现并不知道所谓的Scala集合，但DAO接口返回的却是Scala集合类型（scala.List）而不是Java集合。因为Scala集合要比Java集合强大的多，因此DAO方法的调用者非常希望方法能够返回Scala集合。这样，我们需要将JPA返回的Java集合平滑地转换为Scala集合。

关于回调：Spring用于粘合JPA、JMS等框架的大多数胶水代码都是基于模板模式，比如JpaTemplate、 JmsTemplate等。虽然这些模板通过一些便捷的方法在一定程度上隐藏了底层框架的复杂性，但很多时候我们还是不可避免地要直接访问底层的实现类，如EntityManager、JmsSession等。在这种情况下，Spring通过JpaCallback等回调类来实现我们的愿望。回调方法 doIn…(..)唯一的参数就是指向实现类的引用，比如EntityManager。下面的示例阐述了这种编程模型：

jpaTemplate.execute(new　JpaCallback()　{　
　public　Object　doInJpa(EntityManager　em)　throws　PersistenceException　{　
　//…　do　something　with　the　EntityManager　
　return　null;　
}　
});

上面的代码有两点值得我们注意：首先，匿名内部回调类的实例化需要大量的样板代码。其次，还有一个限制：匿名内部类JpaCallback 之外的所有参数都必须是final的。如果从Scala的视角来看待这种回调模式，我们发现里面充斥的全都是某个“函数”的繁琐实现。我们真正想要的只是能够直接访问EntityManager而已，并不需要匿名内部类，而且还得实现里面的doInJpa(…)方法，这有点太小题大作了。换句话说，我们只需要下面这一行足矣：