b.对应实体：User
@Entity
@Table(name = "user")
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Integer id;
private String name;
private String password;
private String birthday;
// getter,setter
}
c.简历UserRepository接口
public interface UserRepository extends JpaRepository<User, Integer>{}
通过上面3步，所有的工作就做完了，User的基础CRUD都能做了，简约而不简单。
d.我们的测试类UserRepositoryTest
public class UserRepositoryTest {
@Autowired
private UserRepository userRepository;
@Test
public void baseTest() throws Exception {
User user = new User();
user.setName("Jay");
user.setPassword("123456");
user.setBirthday("2008-08-08");
userRepository.save(user);
// userRepository.delete(user);
// userRepository.findOne(1);
}
}
测试通过。
说到这里，和spring已经完成。接下来第三点，基本使用。
4.前面把基础的东西说清楚了，接下来就是spring-data-jpa的正餐了，真正威力的地方。
4.1 我们的系统中一般都会有用户登录这个接口，在不使用spring-data-jpa的时候我们怎么做，首先在service层定义一个登录方法。如：
User login(String name, String password);
然后在serviceImpl中写该方法的实现，大致这样：
@Override
public User login(String name, String password) {
return userDao.login(name, password);
}
接下来，UserDao大概是这么个样子：
User getUserByNameAndPassword(String name, String password);
然后在UserDaoImpl中大概是这么个样子：
public User getUserByNameAndPassword(String name, String password) {
Query query = em.createQuery("select * from User t where t.name = ?1 and t.password = ?2");
query.setParameter(1, name);
query.setParameter(2, password);
return (User) query.getSingleResult();
}
ok，这个代码运行良好，那么这样子大概有十来行代码，我们感觉这个功能实现了，很不错。然而这样子真正简捷么？如果这样子就满足了，那么spring-data-jpa就没有必要存在了，前面提到spring-data-jpa能够帮助你完成业务逻辑代码的处理，那他是怎么处理的呢？这里我们根本不需要UserDaoImpl这个类，只需要在UserRepository接口中定义一个方法
User findByNameAndPassword(String name, String password);
然后在service中调用这个方法就完事了，所有的逻辑只需要这么一行代码，一个没有实现的接口方法。通过debug信息，我们看到输出的sql语句是
select * from user where name = ? and password = ?
跟上面的传统方式一模一样的结果。这简单到令人发指的程度，那么这一能力是如何实现的呢？原理是：spring-data-jpa会根据方法的名字来自动生成sql语句，我们只需要按照方法定义的规则即可，上面的方法findByNameAndPassword，spring-data-jpa规定，方法都以findBy开头，sql的where部分就是NameAndPassword，被spring-data-jpa翻译之后就编程了下面这种形态：
where name = ? and password = ?
在举个例，如果是其他的操作符呢，比如like，前端模糊查询很多都是以like的方式来查询。比如根据名字查询用户，sql就是
select * from user where name like = ?
这里spring-data-jpa规定，在属性后面接关键字，比如根据名字查询用户就成了
User findByNameLike(String name);
被翻译之后的sql就是
select * from user where name like = ?
这也是简单到令人发指，spring-data-jpa所有的语法规定如下图：
通过上面，基本CRUD和基本的业务逻辑操作都得到了解决，我们要做的工作少到仅仅需要在UserRepository接口中定义几个方法，其他所有的工作都由spring-data-jpa来完成。
接下来：就是比较复杂的操作了，比如动态查询，分页，下面详细介绍spring-data-jpa的第二大杀手锏，强大的动态查询能力。
在上面的介绍中，对于我们传统的企业级应用的基本操作已经能够基本上全部实现，企业级应用一般都会有一个模糊查询的功能，并且是多条的查询，在有查询条件的时候我们需要在where后面接上一个 xxx = yyy 或者 xxx like '% + yyy + %'类似这样的sql。那么我们传统的JDBC的做法是使用很多的if语句根据传过来的查询条件来拼sql，mybatis的做法也类似，由于mybatis有强大的动态xml文件的标签，在处理这种问题的时候显得非常的好，但是二者的原理都一致，那spring-data-jpa的原理也同样很类似，这个道理也就说明了解决多表关联动态查询根儿上也就是这么回事。
那么spring-data-jpa的做法是怎么的呢？有两种方式。可以选择其中一种，也可以结合使用，在一般的查询中使用其中一种就够了，就是第二种，但是有一类查询比较棘手，比如报表相关的，报表查询由于涉及的表很多，这些表不一定就是两两之间有关系，比如字典表，就很独立，在这种情况之下，使用拼接sql的方式要容易一些。下面分别介绍这两种方式。
a.使用JPQL,和Hibernate的HQL很类似。
前面说道了在UserRepository接口的同一个包下面建立一个普通类UserRepositoryImpl来表示该类的实现类，同时前面也介绍了完全不需要这个类的存在，但是如果使用JPQL的方式就必须要有这个类。如下：
public class StudentRepositoryImpl {
@PersistenceContext
private EntityManager em;
@SuppressWarnings("unchecked")
public Page<Student> search(User user) {
String dataSql = "select t from User t where 1 = 1";
String countSql = "select count(t) from User t where 1 = 1";
if(null != user && !StringUtils.isEmpty(user.getName())) {
dataSql += " and t.name = ?1";
countSql += " and t.name = ?1";
}
long count(Specification<T> spec);
}
上面说了，使用这种方式我们压根儿就不需要UserRepositoryImpl这个类，说到这里，仿佛我们就发现了spring-data-jpa为什么把Repository和RepositoryImpl文件放在同一个包下面，因为我们的应用很可能根本就一个Impl文件都不存在，那么在那个包下面就只有一堆接口，即使把Repository和RepositoryImpl都放在同一个包下面，也不会造成这个包下面有正常情况下2倍那么多的文件，根本原因：只有接口而没有实现类。
上面我们的UserRepository类继承了JpaRepository和JpaSpecificationExecutor类，而我们的UserRepository这个对象都会注入到UserService里面，于是如果使用这种方式，我们的逻辑直接就写在service里面了，下面的代码：一个学生Student类，一个班级Clazz类，Student里面有一个对象Clazz，在数据库中是clazz_id，这是典型的多对一的关系。我们在配置好entity里面的关系之后。就可以在StudentServiceImpl类中做Student的模糊查询，典型的前端grid的模糊查询。代码是这样子的：
@Service
public class StudentServiceImpl extends BaseServiceImpl<Student> implements StudentService {
if (sort != null) {
query.orderBy(toOrders(sort, root, builder));
}
return applyRepositoryMethodMetadata(em.createQuery(query));
}
一切玄机尽收眼底，这个方法的内容和我们前面使用原生jpa的api的过程是一样的，而再进入
Root<T> root = applySpecificationToCriteria(spec, query);
这个方法：
/**
* Applies the given {@link Specification} to the given {@link CriteriaQuery}.
*
* @param spec can be {@literal null}.
* @param query must not be {@literal null}.
* @return
*/
private <S> Root<T> applySpecificationToCriteria(Specification<T> spec, CriteriaQuery<S> query) {
return employeeList;
}
/**
* Applies the given {@link Specification} to the given {@link CriteriaQuery}.
*
* @param spec can be {@literal null}.
* @param query must not be {@literal null}.
* @return
*/
private <S> Root<T> applySpecificationToCriteria(Specification<T> spec, CriteriaQuery<S> query) {
