每次都看别人的译文，以为翻译很简单。自己第一次翻译一篇简单的Spring Data JPA入门，有很多不足的地方往大家指正。这是原文地址，请点击，可以用Google翻译直接翻译网页（chrome直接右键选择“翻成中文”）。原文作者是这个意思，先写的没用Spring Data Jpa的例子，一大堆，乱七八糟。用了之后，三个方法就搞定，easy!
以下是翻译：
当我们刚刚发布了第一个划时代的Spring Data JPA项目,关于它的特点我想给你们一个核心的介绍.你可能知道,Spring框架对创建一个基于数据访问层的JPA提供支持. 那Spring Data JPA怎样增加这种支持?为了回答这个问题,我想从把数据访问组件用于一个实现使用纯JPA+Spring的样本例子开始,并指出它留下的改进空间.然后我所做的是,将重构实现使用Spring Data JPA功能来解决这些问题.示例项目以及一步一步重构，指导步骤可以在Github中找到.
示例
为了简单起见,我们先从一个常见的小例子开始:我们有Account类和Customer类
@Entity
public class Customer {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
private String firstname;
private String lastname;
// … methods omitted
}
@Entity
public class Account {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@ManyToOne
private Customer customer;
@Temporal(TemporalType.DATE)
private Date expiryDate;
// … methods omitted
}
}
帐户有一个截止日期,我们将使用在稍后的阶段。除此之外,没什么特别的类或映射,它使用JPA注释。现在让我们看看组件管理Account对象:
@Repository
@Transactional(readOnly = true)
class AccountServiceImpl implements AccountService {
@PersistenceContext
private EntityManager em;
@Override
@Transactional
public Account save(Account account) {
if (account.getId() == null) {
em.persist(account);
return account;
} else {
return em.merge(account);
}
}
@Override
public List<Account> findByCustomer(Customer customer) {
TypedQuery query = em.createQuery("select a from Account a where a.customer = ?1", Account.class);
query.setParameter(1, customer);
return query.getResultList();
}
}
我故意叫类为Service来避免名称冲突,当我们开始重构时我们将引入一个repository层。但在概念上这里的类是一个repository,而不是一个service。 那么我们这里实际上有什么?
类被注释为@Repository使能从JPA异常到Spring数据访问异常层次中翻译异常(有点绕）。 除此之外,我们使用@transactional确保save(…)操作是一个正在运行的事务,并允许为findByCustomer(…)设置readOnly-flag(在类级别)。 这将导致一些性能优化在持久性提供者内部中,以及在数据库层上。
正如我们想自由的让客户决定是否在EntityManager(实体管理器)调用merge(…)或persist(…),我们使用Account的id字段来决定我们是否考虑新建一个Account对象。这个逻辑当然可以提取到一个共同的父类,例如我们可能不希望重复让代码为在个域对象的具体repository都实现。 查询方法相当简单:我们创建一个查询,绑定一个参数并执行查询去得到一个结果。这几乎是如此直接,其中一个可以认为是作为实现代码的样板,用有一点想象力,方法签名是可引出的:我们期望一个帐户列表,查询非常接近方法名,我们只是将方法参数绑定到它。 所以你可以看到,这有改进的余地。
Spring Data repository 支持
在开始重构实现之前,请注意,示例项目包含测试用例,能在重构的运行过程中去验证代码仍能工作。 现在让我们看看我们如何能改进实现。Spring Data JPA提供了一个repository编程模型,从接口的每个管理域对象开始:
public interface AccountRepository extends JpaRepository<Account, Long> { … }
定义这个接口有两个目的: 首先,通过扩展JpaRepository我们找一群普通的CRUD方法类型,允许保存、删除账户等等。 第二,这将允许Spring Data JPA repository基础设施扫描这个接口的类路径,并为它创建一个Spring bean。
有Spring 创建一个bean实现了这个接口,所有你需要做的就是使用Spring JPA命名空间和激活repository支持使用适当的元素:
<jpa:repositories base-package="com.acme.repositories" />
扫描com.acme.repositories 下对JpaRepository接口扩展的所有包,并创建一个Spring bean支持SimpleJpaRepository的实现。让我们采取第一步和重构AccountService实现一点去使用我们新引进repository接口:
@Repository
@Transactional(readOnly = true)
class AccountServiceImpl implements AccountService {
@PersistenceContext
private EntityManager em;
@Autowired
private AccountRepository repository;
@Override
@Transactional
public Account save(Account account) {
return repository.save(account);
}
@Override
public List<Account> findByCustomer(Customer customer) {
TypedQuery query = em.createQuery("select a from Account a where a.customer = ?1", Account.class);
query.setParameter(1, customer);
return query.getResultList();
}
}
这种重构后,我们简单委托调用save(…)到repository。 默认repository实现将考虑一个新实体如果其id属性为空就像你在前面的示例中看到(注意,你可以获得更详细的控制而不是决定，如果必要的话)。 此外,我们可以摆脱@ transactional注释方法,Spring Data JPA repository实现的CRUD方法已经用@ transactional注释。
接下来我们将重构查询方法。让我们如同对save方法,对query方法遵循相同的授权策略。我们在repository接口引入一个查询方法,并用我们最初的方法委托给新引入的方法:
@Transactional(readOnly = true)
public interface AccountRepository extends JpaRepository<Account, Long> {
List<Account> findByCustomer(Customer customer);
}
@Repository
@Transactional(readOnly = true)
class AccountServiceImpl implements AccountService {
@Autowired
private AccountRepository repository;
@Override
@Transactional
public Account save(Account account) {
return repository.save(account);
}
@Override
public List<Account> findByCustomer(Customer customer) {
return repository.findByCustomer(Customer customer);
}
}
让我在这里的事务处理添加一个快速写入。在这个非常简单的情况下,我们完全可以从AccountServiceImpl类实体中删除@ transactional注释,正如repository的CRUD方法是事务,查询方法在repository接口已经是标有@ transactional(readOnly = true)。 当前设置,在service层的方法标记为事务性的(即使不需要)是最好的,因为当看见service层,即业务操作正是发生在一个事务中时,它是显式地清除。 除此之外,如果一个service层方法被修改为多重调用repository方法,仍将在单个事务中执行的所有代码,正如repository的内部事务将只简单地加入到在service层开始的外部事务。repository类的事务行为和调整它的可能性是在参考文档中详细记录。
尝试再次运行测试用例,发现它的工作原理。停止,我们不提供任何实现findByCustomer(…)对吗?这是如何工作的呢?
Query 方法
当Spring Data JPA创建为Accountrepository接口检查所有已定义的查询方法的Spring bean实例,并推导出它们的查询。 默认情况下Spring Data JPA将自动解析方法名和创建一个查询。查询是使用JPA标准API实现。在这种情况下,findByCustomer(…)方法在逻辑上等同于JPQL查询select a from Account a where a.customer = ?1。解析器的分析方法名支持相当大量的关键字集,比如:And, Or, GreaterThan, LessThan, Like, IsNull, 等等。 如果你喜欢,还可以添加OrderBy条款。一个详细的概述请查看参考文档。这种机制给了我们一个查询方法的编程模型，就像你以前从Grails或Spring Roo。
现在,让我们假设你希望对所使用的查询进行显式。这样做你可以声明一个JPA命名查询,遵循命名约定(在本例中Account.findByCustomer)在实体上或在你的orm.xml注释。或者你可以用@Query注释你的repository方法:
@Transactional(readOnly = true)
public interface AccountRepository extends JpaRepository<Account, Long> {
@Query("<JPQ statement here>")
List<Account> findByCustomer(Customer customer);
}
现在让我们做一个比较前后的CustomerServiceImpl应用功能,到目前为止,我们已经看到:
@Repository
@Transactional(readOnly = true)
public class CustomerServiceImpl implements CustomerService {
@PersistenceContext
private EntityManager em;
@Override
public Customer findById(Long id) {
return em.find(Customer.class, id);
}
@Override
public List<Customer> findAll() {
return em.createQuery("select c from Customer c", Customer.class).getResultList();
}
@Override
public List<Customer> findAll(int page, int pageSize) {
TypedQuery query = em.createQuery("select c from Customer c", Customer.class);
query.setFirstResult(page * pageSize);
query.setMaxResults(pageSize);
return query.getResultList();
}
@Override
@Transactional
public Customer save(Customer customer) {
// Is new?
if (customer.getId() == null) {
em.persist(customer);
return customer;
} else {
return em.merge(customer);
}
}
@Override
public List<Customer> findByLastname(String lastname, int page, int pageSize) {
TypedQuery query = em.createQuery("select c from Customer c where c.lastname = ?1", Customer.class);
query.setParameter(1, lastname);
query.setFirstResult(page * pageSize);
query.setMaxResults(pageSize);
return query.getResultList();
}
}
好的,让我们先创建CustomerRepository和去掉CRUD方法:
@Transactional(readOnly = true)
public interface CustomerRepository extends JpaRepository<Customer, Long> { … }
@Repository
@Transactional(readOnly = true)
public class CustomerServiceImpl implements CustomerService {
@PersistenceContext
private EntityManager em;
@Autowired
private CustomerRepository repository;
@Override
public Customer findById(Long id) {
return repository.findById(id);
}
@Override
public List<Customer> findAll() {
return repository.findAll();
}
@Override
public List<Customer> findAll(int page, int pageSize) {
TypedQuery query = em.createQuery("select c from Customer c", Customer.class);
query.setFirstResult(page * pageSize);
query.setMaxResults(pageSize);
return query.getResultList();
}
@Override
@Transactional
public Customer save(Customer customer) {
return repository.save(customer);
}
@Override
public List<Customer> findByLastname(String lastname, int page, int pageSize) {
TypedQuery query = em.createQuery("select c from Customer c where c.lastname = ?1", Customer.class);
query.setParameter(1, lastname);
query.setFirstResult(page * pageSize);
query.setMaxResults(pageSize);
return query.getResultList();
}
}
目前为止一切都很顺利。现在剩下两个方法处理一个常见的场景:你不想访问所有给定查询的实体,而是只有一个页面(如10页中的1页)。 现在这是解决两个整数,适当限制查询。这有两个问题。 其实两个整数一起代表一个概念,在这里不明确。除此之外,我们返回一个简单的列表,所以我们失去元数据信息的实际页面数据:这是第一页吗?这是最后一个吗?总共有多少页? Spring Data提供一个由两个接口组成的抽象概念:可分页(捕捉分页请求信息)以及页面(捕获结果以及元信息)。我们试着添加findByLastname(…)去repository接口和重写findAll(…)和findByLastname(…)如下:
@Transactional(readOnly = true)
public interface CustomerRepository extends JpaRepository<Customer, Long> {
Page<Customer> findByLastname(String lastname, Pageable pageable);
}
@Override
public Page<Customer> findAll(Pageable pageable) {
return repository.findAll(pageable);
}
@Override
public Page<Customer> findByLastname(String lastname, Pageable pageable) {
return repository.findByLastname(lastname, pageable);
}
确保你根据签名变化调整测试用例但是他们应该会正确运行。这里有两件事情可以归结为:我们有CRUD方法支持分页以及查询执行机制了解可分页参数。 在这个阶段，我们的包装类实际上已经过时了，作为一个客户端可以直接使用我们的repository接口。我们摆脱了整个实现代码。
总结
在这篇博客的过程中我们已经减少了 repository类编写的代码数量，用2个接口的3个方法和XML的一行:
@Transactional(readOnly = true)
public interface CustomerRepository extends JpaRepository<Customer, Long> {
Page<Customer> findByLastname(String lastname, Pageable pageable);
}
@Transactional(readOnly = true)
public interface AccountRepository extends JpaRepository<Account, Long> {
List<Account> findByCustomer(Customer customer);
}
<jpa:repositories base-package="com.acme.repositories" />
我们有类型安全的CRUD方法,查询执行和分页。最酷的是,这不仅对JPA基础repositories工作,而且非关系数据库。第一个非关系数据库来支持这种方法将是MongoDB，它作为Spring Data文档的一部分在几天内发布。你会得到相同的特性Mongo DB,我们正在努力支持其他数据库。还有额外的特性研究(例如实体审计、集成的自定义数据访问代码),我们将在即将到来的博文发表。
翻译总结
恭喜你看完了这篇拙作。我自己总结一下，翻译得不是很好。大家看看原文作者用了Spring Data JPA的例子就行。我看他的源码里并没有xml文件，这篇译文知识量很少，不要花太多时间，没看懂也没关系(翻译得太烂)。这里贴个developerWorks链接--点击，你可以去研究研究。
