【原创】纯干货,Spring-data-jpa详解,全方位介绍。

本篇进行Spring-data-jpa的介绍,几乎涵盖该框架的全部方面,在平常的开发当中,基本上能知足全部需求。这里不讲解JPA和Spring-data-jpa单独使用,全部的内容都是在和Spring整合的环境中实现。若是须要了解该框架的入门,百度一下,不少入门的介绍。在这篇文章的接下来一篇,会有一个系列来说解mybatis,这个系列从mybatis的入门开始,到基本使用,和spring整合,和第三方插件整合,缓存,插件,最后会持续到mybatis的架构,源码解释,重点会介绍几个重要的设计模式,这样一个体系。基本上讲完以后,mybatis在你面前就没有了秘密,你能解决mybatis的几乎全部问题,而且在开发过程当中至关的方便,得心应手。前端

这篇文章因为介绍的类容很全,所以很长,若是你须要,那么能够耐心的看完,本人经历了很长时间的学识,使用,研究的心血浓缩成为这么短短的一篇博客。mysql

大体整理一个提纲:redis

  一、Spring-data-jpa的基本介绍;spring

  二、和Spring整合;sql

  三、基本的使用方式;mongodb

  四、复杂查询,包括多表关联,分页,排序等;数据库

如今开始:express

  一、Spring-data-jpa的基本介绍:JPA诞生的原因是为了整合第三方ORM框架,创建一种标准的方式,百度百科说是JDK为了实现ORM的天下归一,目前也是在按照这个方向发展,可是还没能彻底实现。在ORM框架中,Hibernate是一支很大的部队,使用很普遍,也很方便,能力也很强,同时Hibernate也是和JPA整合的比较良好,咱们能够认为JPA是标准,事实上也是,JPA几乎都是接口,实现都是Hibernate在作,宏观上面看,在JPA的统一之下Hibernate很良好的运行。编程

  上面阐述了JPA和Hibernate的关系,那么Spring-data-jpa又是个什么东西呢?这地方须要稍微解释一下,咱们作Java开发的都知道Spring的强大,到目前为止,企业级应用Spring几乎是无所不能,无所不在,已是事实上的标准了,企业级应用不使用Spring的几乎没有,这样说没错吧。而Spring整合第三方框架的能力又很强,他要作的不只仅是个最先的IOC容器这么简单一回事,如今Spring涉及的方面太广,主要是体如今和第三方工具的整合上。而在与第三方整合这方面,Spring作了持久化这一块的工做,我我的的感受是Spring但愿把持久化这块内容也拿下。因而就有了Spring-data-**这一系列包。包括,Spring-data-jpa,Spring-data-template,Spring-data-mongodb,Spring-data-redis,还有个民间产品,mybatis-spring,和前面相似,这是和mybatis整合的第三方包,这些都是干的持久化工具干的事儿。设计模式

  这里介绍Spring-data-jpa,表示与jpa的整合。

  二、咱们都知道,在使用持久化工具的时候,通常都有一个对象来操做数据库,在原生的Hibernate中叫作Session,在JPA中叫作EntityManager,在MyBatis中叫作SqlSession,经过这个对象来操做数据库。咱们通常按照三层结构来看的话,Service层作业务逻辑处理,Dao层和数据库打交道,在Dao中,就存在着上面的对象。那么ORM框架自己提供的功能有什么呢?答案是基本的CRUD,全部的基础CRUD框架都提供,咱们使用起来感受很方便,很给力,业务逻辑层面的处理ORM是没有提供的,若是使用原生的框架,业务逻辑代码咱们通常会自定义,会本身去写SQL语句,而后执行。在这个时候,Spring-data-jpa的威力就体现出来了,ORM提供的能力他都提供,ORM框架没有提供的业务逻辑功能Spring-data-jpa也提供,全方位的解决用户的需求。使用Spring-data-jpa进行开发的过程当中,经常使用的功能,咱们几乎不须要写一条sql语句,至少在我看来,企业级应用基本上能够不用写任何一条sql,固然spring-data-jpa也提供本身写sql的方式,这个就看我的怎么选择,均可以。我以为都行。

  2.1与Spring整合咱们从spring配置文件开始,为了节省篇幅,这里我只写出配置文件的结构。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:p="http://www.springframework.org/schema/p" 
    xmlns:aop="http://www.springframework.org/schema/aop" 
    xmlns:tx="http://www.springframework.org/schema/tx" 
    xmlns:context="http://www.springframework.org/schema/context" 
    xmlns:mongo="http://www.springframework.org/schema/data/mongo"
    xmlns:jpa="http://www.springframework.org/schema/data/jpa"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
           http://www.springframework.org/schema/aop     
           http://www.springframework.org/schema/aop/spring-aop-3.0.xsd   
           http://www.springframework.org/schema/tx
           http://www.springframework.org/schema/tx/spring-tx-3.0.xsd
           http://www.springframework.org/schema/context     
           http://www.springframework.org/schema/context/spring-context-3.0.xsd
           http://www.springframework.org/schema/data/mongo
           http://www.springframework.org/schema/data/mongo/spring-mongo-1.0.xsd
           http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd">

    <!-- 数据库链接 -->
    <context:property-placeholder location="classpath:your-config.properties" ignore-unresolvable="true" />
    <!-- service包 -->
    <context:component-scan base-package="your service package" />
    <!-- 使用cglib进行动态代理 -->
    <aop:aspectj-autoproxy proxy-target-class="true" />
    <!-- 支持注解方式声明式事务 -->
    <tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="true" />
    <!-- dao -->
    <jpa:repositories base-package="your dao package" repository-impl-postfix="Impl" entity-manager-factory-ref="entityManagerFactory" transaction-manager-ref="transactionManager" />
    <!-- 实体管理器 -->
    <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
        <property name="dataSource" ref="dataSource" />
        <property name="packagesToScan" value="your entity package" />
        <property name="persistenceProvider">
            <bean class="org.hibernate.ejb.HibernatePersistence" />
        </property>
        <property name="jpaVendorAdapter">
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
                <property name="generateDdl" value="false" />
                <property name="database" value="MYSQL" />
                <property name="databasePlatform" value="org.hibernate.dialect.MySQL5InnoDBDialect" />
                <!-- <property name="showSql" value="true" /> -->
            </bean>
        </property>
        <property name="jpaDialect">
            <bean class="org.springframework.orm.jpa.vendor.HibernateJpaDialect" />
        </property>
        <property name="jpaPropertyMap">
            <map>
                <entry key="hibernate.query.substitutions" value="true 1, false 0" />
                <entry key="hibernate.default_batch_fetch_size" value="16" />
                <entry key="hibernate.max_fetch_depth" value="2" />
                <entry key="hibernate.generate_statistics" value="true" />
                <entry key="hibernate.bytecode.use_reflection_optimizer" value="true" />
                <entry key="hibernate.cache.use_second_level_cache" value="false" />
                <entry key="hibernate.cache.use_query_cache" value="false" />
            </map>
        </property>
    </bean>
    
    <!-- 事务管理器 -->
    <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
        <property name="entityManagerFactory" ref="entityManagerFactory"/>
    </bean>
    
    <!-- 数据源 -->
    <bean id="dataSource" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" destroy-method="close">
        <property name="driverClassName" value="${driver}" />
        <property name="url" value="${url}" />
        <property name="username" value="${userName}" />
        <property name="password" value="${password}" />
        <property name="initialSize" value="${druid.initialSize}" />
        <property name="maxActive" value="${druid.maxActive}" />
        <property name="maxIdle" value="${druid.maxIdle}" />
        <property name="minIdle" value="${druid.minIdle}" />
        <property name="maxWait" value="${druid.maxWait}" />
        <property name="removeAbandoned" value="${druid.removeAbandoned}" />
        <property name="removeAbandonedTimeout" value="${druid.removeAbandonedTimeout}" />
        <property name="timeBetweenEvictionRunsMillis" value="${druid.timeBetweenEvictionRunsMillis}" />
        <property name="minEvictableIdleTimeMillis" value="${druid.minEvictableIdleTimeMillis}" />
        <property name="validationQuery" value="${druid.validationQuery}" />
        <property name="testWhileIdle" value="${druid.testWhileIdle}" />
        <property name="testOnBorrow" value="${druid.testOnBorrow}" />
        <property name="testOnReturn" value="${druid.testOnReturn}" />
        <property name="poolPreparedStatements" value="${druid.poolPreparedStatements}" />
        <property name="maxPoolPreparedStatementPerConnectionSize" value="${druid.maxPoolPreparedStatementPerConnectionSize}" />
        <property name="filters" value="${druid.filters}" />
    </bean>
    
    <!-- 事务 -->
    <tx:advice id="txAdvice" transaction-manager="transactionManager">
        <tx:attributes>
            <tx:method name="*" />
            <tx:method name="get*" read-only="true" />
            <tx:method name="find*" read-only="true" />
            <tx:method name="select*" read-only="true" />
            <tx:method name="delete*" propagation="REQUIRED" />
            <tx:method name="update*" propagation="REQUIRED" />
            <tx:method name="add*" propagation="REQUIRED" />
            <tx:method name="insert*" propagation="REQUIRED" />
        </tx:attributes>
    </tx:advice>
    <!-- 事务入口 -->
    <aop:config>
        <aop:pointcut id="allServiceMethod" expression="execution(* your service implements package.*.*(..))" />
        <aop:advisor pointcut-ref="allServiceMethod" advice-ref="txAdvice" />
    </aop:config>

</beans>

  2.2对上面的配置文件进行简单的解释,只对“实体管理器”和“dao”进行解释,其余的配置在任何地方都差不太多。

    1.对“实体管理器”解释:咱们知道原生的jpa的配置信息是必须放在META-INF目录下面的,而且名字必须叫作persistence.xml,这个叫作persistence-unit,就叫作持久化单元,放在这下面咱们感受不方便,很差,因而Spring提供了

org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean

这样一个类,可让你的为所欲为的起这个配置文件的名字,也能够为所欲为的修改这个文件的位置,只须要在这里指向这个位置就行。然而更加方便的作法是,直接把配置信息就写在这里更好,因而就有了这实体管理器这个bean。使用

<property name="packagesToScan" value="your entity package" />

这个属性来加载咱们的entity。

  2.3 解释“dao”这个bean。这里衍生一下,进行一下名词解释,咱们知道dao这个层叫作Data Access Object,数据库访问对象,这是一个普遍的词语,在jpa当中,咱们还有一个词语叫作Repository,这里咱们通常就用Repository结尾来表示这个dao,好比UserDao,这里咱们使用UserRepository,固然名字无所谓,随意取,你能够意会一下个人意思,感觉一下这里的含义和区别,同理,在mybatis中咱们通常也不叫dao,mybatis因为使用xml映射文件(固然也提供注解,可是官方文档上面表示在有些地方,好比多表的复杂查询方面,注解仍是无解,只能xml),咱们通常使用mapper结尾,好比咱们也不叫UserDao,而叫UserMapper。

  上面拓展了一下关于dao的解释,那么这里的这个配置信息是什么意思呢?首先base-package属性,表明你的Repository接口的位置,repository-impl-postfix属性表明接口的实现类的后缀结尾字符,好比咱们的UserRepository,那么他的实现类就叫作UserRepositoryImpl,和咱们平时的使用习惯彻底一致,于此同时,spring-data-jpa的习惯是接口和实现类都须要放在同一个包里面(不知道有没有其余方式能分开放,这不是重点,放在一块儿也无所谓,影响不大),再次的,这里咱们的UserRepositoryImpl这个类的定义的时候咱们不须要去指定实现UserRepository接口,根据spring-data-jpa自动就能判断两者的关系。

  好比:咱们的UserRepository和UserRepositoryImpl这两个类就像下面这样来写。

public interface UserRepository extends JpaRepository<User, Integer>{}
public class UserRepositoryImpl {}

  那么这里为何要这么作呢?缘由是:spring-data-jpa提供基础的CRUD工做,同时也提供业务逻辑的功能(前面说了,这是该框架的威力所在),因此咱们的Repository接口要作两项工做,继承spring-data-jpa提供的基础CRUD功能的接口,好比JpaRepository接口,同时本身还须要在UserRepository这个接口中定义本身的方法,那么致使的结局就是UserRepository这个接口中有不少的方法,那么若是咱们的UserRepositoryImpl实现了UserRepository接口,致使的后果就是咱们势必须要重写里面的全部方法,这是Java语法的规定,如此一来,悲剧就产生了,UserRepositoryImpl里面咱们有不少的@Override方法,这显然是不行的,结论就是,这里咱们不用去写implements部分。

  spring-data-jpa实现了上面的能力,那他是怎么实现的呢?这里咱们经过源代码的方式来呈现他的前因后果,这个过程当中cglib发挥了杰出的做用。

  在spring-data-jpa内部,有一个类,叫作

public class SimpleJpaRepository<T, ID extends Serializable> implements JpaRepository<T, ID>,
        JpaSpecificationExecutor<T>

咱们能够看到这个类是实现了JpaRepository接口的,事实上若是咱们按照上面的配置,在同一个包下面有UserRepository,可是没有UserRepositoryImpl这个类的话,在运行时期UserRepository这个接口的实现就是上面的SimpleJpaRepository这个接口。而若是有UserRepositoryImpl这个文件的话,那么UserRepository的实现类就是UserRepositoryImpl,而UserRepositoryImpl这个类又是SimpleJpaRepository的子类,如此一来就很好的解决了上面的这个不用写implements的问题。咱们经过阅读这个类的源代码能够发现,里面包装了entityManager,底层的调用关系仍是entityManager在进行CRUD。

  3. 下面咱们经过一个完整的项目来基本使用spring-data-jpa,而后咱们在介绍他的高级用法。

  a.数据库建表:user,主键自增

  

  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";
        }
        
        Query dataQuery = em.createQuery(dataSql);
        Query countQuery = em.createQuery(countSql);
        
        if(null != user && !StringUtils.isEmpty(user.getName())) {
            dataQuery.setParameter(1, user.getName());
            countQuery.setParameter(1, user.getName());
        }long totalSize = (long) countQuery.getSingleResult();
        Page<User> page = new Page();
        page.setTotalSize(totalSize);
        List<User> data = dataQuery.getResultList();
        page.setData(data);
        return page;
    }
    
}

经过上面的方法,咱们查询而且封装了一个User对象的分页信息。代码可以良好的运行。这种作法也是咱们传统的经典作法。那么spring-data-jpa还有另一种更好的方式,那就是所谓的类型检查的方式,上面咱们的sql是字符串,没有进行类型检查,而下面的方式就使用了类型检查的方式。这个道理在mybatis中也有体现,mybatis可使用字符串sql的方式,也可使用接口的方式,而mybatis的官方推荐使用接口方式,由于有类型检查,会更安全。

  b.使用JPA的动态接口,下面的接口我把注释删了,为了节省篇幅,注释也没什么用,看方法名字大概都能猜到是什么意思。

public interface JpaSpecificationExecutor<T> {

    T findOne(Specification<T> spec);

    List<T> findAll(Specification<T> spec);

    Page<T> findAll(Specification<T> spec, Pageable pageable);

    List<T> findAll(Specification<T> spec, Sort sort);

    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 {
    
    @Autowired
    private StudentRepository studentRepository;
    
    @Override
    public Student login(Student student) {
        return studentRepository.findByNameAndPassword(student.getName(), student.getPassword());
    }

    @Override
    public Page<Student> search(final Student student, PageInfo page) {
        return studentRepository.findAll(new Specification<Student>() {
            @Override
            public Predicate toPredicate(Root<Student> root, CriteriaQuery<?> query, CriteriaBuilder cb) {
                
                Predicate stuNameLike = null;
                if(null != student && !StringUtils.isEmpty(student.getName())) {
           // 这里也能够root.get("name").as(String.class)这种方式来强转泛型类型 stuNameLike
= cb.like(root.<String> get("name"), "%" + student.getName() + "%"); } Predicate clazzNameLike = null; if(null != student && null != student.getClazz() && !StringUtils.isEmpty(student.getClazz().getName())) { clazzNameLike = cb.like(root.<String> get("clazz").<String> get("name"), "%" + student.getClazz().getName() + "%"); } if(null != stuNameLike) query.where(stuNameLike); if(null != clazzNameLike) query.where(clazzNameLike); return null; } }, new PageRequest(page.getPage() - 1, page.getLimit(), new Sort(Direction.DESC, page.getSortName()))); } }

先解释下这里的意思,而后咱们在结合框架的源码来深刻分析。

这里咱们是2个表关联查询,查询条件包括Student表和Clazz表,相似的2个以上的表方式差很少,可是正如上面所说,这种作法适合全部的表都是两两可以关联上的,涉及的表太多,或者是有一些字典表,那就使用sql拼接的方式,简单一些。

先简单解释一下代码的含义,而后结合框架源码来详细分析。两个Predicate对象,Predicate按照中文意思是判断,断言的意思,那么放在咱们的sql中就是where后面的东西,好比

name like '% + jay + %';

下面的PageRequest表明分页信息,PageRequest里面的Sort对象是排序信息。上面的代码事实上是在动态的组合最终的sql语句,这里使用了一个策略模式,或者callback,就是

studentRepository.findAll(一个接口)

studentRepository接口方法调用的参数是一个接口,而接口的实现类调用这个方法的时候,在内部,参数对象的实现类调用本身的toPredicate这个方法的实现内容,能够体会一下这里的思路,就是传一个接口,而后接口的实现本身来定义,这个思路在nettyJavaScript中体现的特别明显,特别是JavaScript的框架中大量的这种方式,JS框架不少的作法都是上来先闭包,和浏览器的命名空间分开,而后入口方法就是一个回调,好比ExtJS:

Ext.onReady(function() {
    // xxx
});

参数是一个function,其实在框架内部就调用了这个参数,因而这个这个方法执行了。这种模式还有一个JDK的排序集合上面也有体现,咱们的netty框架也采用这种方式来实现异步IO的能力。

接下来结合框架源码来详细介绍这种机制,以及这种机制提供给咱们的好处。

 这里首先从JPA的动态查询开始提及,在JPA提供的API中,动态查询大概有这么一些方法,

从名字大概能够看出这些方法的意义,跟Hibernate或者一些其余的工具也都差很少,这里咱们介绍参数为CriteriaQuery类型的这个方法,若是咱们熟悉多种ORM框架的话,不难发现都有一个Criteria相似的东西,中文意思是“条件”的意思,这就是各个框架构建动态查询的主体,Hibernate甚至有两种,在线和离线两种Criteria,mybatis也能从Example中建立Criteria,而且添加查询条件。

那么第一步就须要构建出这个参数CriteriaQuery类型的参数,这里使用建造者模式,

CriteriaBuilder builder = em.getCriteriaBuilder();
CriteriaQuery<Student> query = builder.createQuery(Student.class);

接下来:

Root<Student> root = query.from(Student.class);

在这里,咱们看方法名from,意思是获取Student的Root,其实也就是个Student的包装对象,就表明这条sql语句里面的主体。接下来:

        Predicate p1 = builder.like(root.<String> get("name"), "%" + student.getName() + "%");
        Predicate p2 = builder.equal(root.<String> get("password"), student.getPassword());

Predicate是判断的意思,放在sql语句中就是where后面 xxx = yyy, xxx like yyy这种,也就是查询条件,这里构造了2个查询条件,分别是根据student的name属性进行like查询和根据student的password进行“=”查询,在sql中就是

name like = ? and password = ?

这种形式,接下来

query.where(p1, p2);

这样子一个完整的动态查询就构建完成了,接下来调用getSingleResult或者getResultList返回结果,这里jpa的单个查询若是为空的话会报异常,这点感受框架设计的很差,若是查询为空直接返回一个null或者一个空的List更好一点。

这是jpa原生的动态查询方式,过程大体就是,建立builder => 建立Query => 构造条件 => 查询。这么4个步骤,这里代码运行良好,若是不使用spring-data-jpa,咱们就须要这么来作,可是spring-data-jpa帮咱们作得更为完全,从上面的4个步骤中,咱们发现:全部的查询除了第三步不同,其余几步都是如出一辙的,不使用spring-data-jpa的状况下,咱们要么4步骤写完,要么本身写个工具类,封装一下,这里spring-data-jpa就是帮咱们完成的这样一个动做,那就是在JpaSpecification<T>这个接口中的

Page<T> findAll(Specification<T> spec, Pageable pageable);

这个方法,前面说了,这是个策略模式,参数spec是个接口,前面也说了框架内部对于这个接口有默认的实现类

@Repository
@Transactional(readOnly = true)
public class SimpleJpaRepository<T, ID extends Serializable> implements JpaRepository<T, ID>,
        JpaSpecificationExecutor<T> {
   
}

,咱们的Repository接口就是继承这个接口,而经过cglib的RepositoryImpl的代理类也是这个类的子类,默认也就实现了该方法。这个方法的方法体是这样的:

    /*
     * (non-Javadoc)
     * @see org.springframework.data.jpa.repository.JpaSpecificationExecutor#findOne(org.springframework.data.jpa.domain.Specification)
     */
    public T findOne(Specification<T> spec) {

        try {
            return getQuery(spec, (Sort) null).getSingleResult();
        } catch (NoResultException e) {
            return null;
        }
    }

这里的

getQuery(spec, (Sort) null)

返回类型是

TypedQuery<T>

进入这个getQuery方法:

    /**
     * Creates a {@link TypedQuery} for the given {@link Specification} and {@link Sort}.
     * 
     * @param spec can be {@literal null}.
     * @param sort can be {@literal null}.
     * @return
     */
    protected TypedQuery<T> getQuery(Specification<T> spec, Sort sort) {

        CriteriaBuilder builder = em.getCriteriaBuilder();
        CriteriaQuery<T> query = builder.createQuery(getDomainClass());

        Root<T> root = applySpecificationToCriteria(spec, query);
        query.select(root);

        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) {

        Assert.notNull(query);
        Root<T> root = query.from(getDomainClass());

        if (spec == null) {
            return root;
        }

        CriteriaBuilder builder = em.getCriteriaBuilder();
        Predicate predicate = spec.toPredicate(root, query, builder);

        if (predicate != null) {
            query.where(predicate);
        }

        return root;
    }

咱们能够发现spec参数调用了toPredicate方法,也就是咱们前面service里面匿名内部类的实现。

到这里spring-data-jpa的默认实现已经彻底明了。总结一下使用动态查询:前面说的原生api须要4步,而使用spring-data-jpa只须要一步,那就是重写匿名内部类的toPredicate方法。在重复一下上面的Student和Clazz的查询代码,

 1     @Override
 2     public Page<Student> search(final Student student, PageInfo page) {
 4         return studentRepository.findAll(new Specification<Student>() {
 5             @Override
 6             public Predicate toPredicate(Root<Student> root, CriteriaQuery<?> query, CriteriaBuilder cb) {
 7                 
 8                 Predicate stuNameLike = null;
 9                 if(null != student && !StringUtils.isEmpty(student.getName())) {
10                     stuNameLike = cb.like(root.<String> get("name"), "%" + student.getName() + "%");
11                 }
12                 
13                 Predicate clazzNameLike = null;
14                 if(null != student && null != student.getClazz() && !StringUtils.isEmpty(student.getClazz().getName())) {
15                     clazzNameLike = cb.like(root.<String> get("clazz").<String> get("name"), "%" + student.getClazz().getName() + "%");
16                 }
17                 
18                 if(null != stuNameLike) query.where(stuNameLike);
19                 if(null != clazzNameLike) query.where(clazzNameLike);
20                 return null;
21             }
22         }, new PageRequest(page.getPage() - 1, page.getLimit(), new Sort(Direction.DESC, page.getSortName())));
23     }

到这里位置,spring-data-jpa的介绍基本上就完成了,涵盖了该框架使用的方方面面。接下来还有一块比较实用的东西,咱们看到上面第15行位置的条件查询,这里使用了一个多级的get,这个是spring-data-jpa支持的,就是嵌套对象的属性,这种作法通常咱们叫方法的级联调用,就是调用的时候返回本身自己,这个在处理xml的工具中比较常见,主要是为了代码的美观做用,没什么其余的用途。

最后还有一个小问题,咱们上面说了使用动态查询和JPQL两种方式均可以,在咱们使用JPQL的时候,他的语法和常规的sql有点不太同样,以Student、Clazz关系为例,好比:

select * from student t left join clazz tt on t.clazz_id = tt.id

这是一个很常规的sql,可是JPQL是这么写:

select t from Student t left join t.clazz tt

left join右边直接就是t的属性,而且也没有了on t.clazz_id == tt.id,然而并不会出现笛卡尔积,这里解释一下为何没有这个条件,在咱们的实体中配置了属性的映射关系,而且ORM框架的最核心的目的就是要让咱们以面向对象的方式来操做数据库,显然咱们在使用这些框架的时候就不须要关心数据库了,只须要关系对象,而t.clazz_id = tt.id这个是数据库的字段,因为配置了字段映射,框架内部本身就会去处理,因此不须要on t.clazz_id = tt.id就是合理的。

  前面介绍了spring-data-jpa的使用,还有一点忘了,悲观所和乐观锁问题,这里的乐观锁比较简单,jpa有提供注解@Version,加上该注解,自动实现乐观锁,byId修改的时候sql自动变成:update ... set ... where id = ? and version = ?,比较方便。

 in操做的查询:

  在平常手动写sql的时候有in这种查询是比较多的,好比select * from user t where t.id in (1, 2, 3);有人说in的效率不高,要少用,可是其实只要in是主键,或者说是带有索引的,效率是很高的,mysql中若是in是子查询貌似不会走索引,不过我我的经验,在我遇到的实际应用中,in(ids)这种是比较多的,因此通常来讲是没有性能问题的。

  那么,sql里面比较好写,可是若是使用spring-data-jpa的动态查询方式呢,就和前面的稍微有点区别。大体上是这么一个思路:

if(!CollectionUtils.isEmpty(ids)) {
    In<Long> in = cb.in(root.<Long> get("id"));
    for (Long id : parentIds) {
        in.value(id);
    }
    query.where(in);
}

  cb建立一个in的Predicate,而后给这个in赋值,最后把in加到where条件中。

手动配置锁:

  spring-data-jpa支持注解方式的sql,好比:@Query(xxx),另外,关于锁的问题,在实体中的某个字段配置@Version是乐观锁,有时候为了使用一个悲观锁,或者手动配置一个乐观锁(若是实体中没有version字段),那么可使用@Lock这个注解,它可以被解析成为相关的锁。

一对多、多对多查询(查询条件在关联对象中时):

  一、在JPA中,一个实体中若是存在多个关联对象,那么不能同时eager获取,只能有一个是eager获取,其余只能lazy;在Hibernate当中有几种独有的解决方法,在JPA当中有2中方法,i.就是前面的改为延时加载;ii.把关联对象的List改为Set(List容许重复,在多层抓去的时候没法完成映射,Hibernate默认抓去4层,在第三层的时候若是是List就没法完成映射)。

  二、在多对多的查询中,咱们可使用JPQL,也可使用原生SQL,同时还可使用动态查询,这里介绍多对多的动态查询,这里有一个条件比较苛刻,那就是查询参数是关联对象的属性,一对多相似,多对一能够利用上面介绍的级联获取属性的方式。这里介绍这种方式的目的是为了更好的利用以面向对象的方式进行动态查询。

  举例:2张表,分别是Employee(id, name)和Company(id, name),两者是多对多的关系,那么当查询Employee的时候,条件是更具公司名称。那么作法以下:

    @Override
    public List<Employee> findByCompanyName(final String companyName) {
        
        List<Employee> employeeList = employeeRepository.findAll(new Specification<Employee>() {
            public Predicate toPredicate(Root<Employee> root, CriteriaQuery<?> query, CriteriaBuilder cb) {
//                ListJoin<Employee, Company> companyJoin = root.join(root.getModel().getList("companyList", Company.class), JoinType.LEFT);
                Join<Employee, Company> companyJoin = root.join("companyList", JoinType.LEFT);
                return cb.equal(companyJoin.get("name"), companyName);
            }
        });
        
        return employeeList;
    }

     咱们可使用上面注释掉的方式,也可使用下面这种比较简单的方式。由于我我的的习惯是尽可能不去写DAO的实现类,除非查询特别复杂,万不得已的状况下采用,不然我我的比较偏向于这种方式。

  上面的状况若是更为极端的话,关联多个对象,能够按照下面的方式:

    @Override
    public List<Employee> findByCompanyName(final String companyName, final String wage) {
        
        List<Employee> employeeList = employeeRepository.findAll(new Specification<Employee>() {
            public Predicate toPredicate(Root<Employee> root, CriteriaQuery<?> query, CriteriaBuilder cb) {
//                ListJoin<Employee, Company> companyJoin = root.join(root.getModel().getList("companyList", Company.class), JoinType.LEFT);
                Join<Employee, Company> companyJoin = root.join("companySet", JoinType.LEFT);
                Join<Employee, Wage> wageJoin = root.join("wageSet", JoinType.LEFT);
                Predicate p1 = cb.equal(companyJoin.get("name"), companyName);
                Predicate p2 = cb.equal(wageJoin.get("name"), wage);
//              return cb.and(p1, p2);根据spring-data-jpa的源码,能够返回一个Predicate,框架内部会自动作query.where(p)的操做,也能够直接在这里处理,而后返回null,///              也就是下面一段源码中的实现
                query.where(p1, p2);
                return null;
            }
        });
        
        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) {

        Assert.notNull(query);
        Root<T> root = query.from(getDomainClass());

        if (spec == null) {
            return root;
        }

        CriteriaBuilder builder = em.getCriteriaBuilder();
        Predicate predicate = spec.toPredicate(root, query, builder);
    // 这里若是咱们重写的toPredicate方法的返回值predicate不为空,那么调用query.where(predicate)
        if (predicate != null) {
            query.where(predicate);
        }

        return root;
    }

 

说明:虽说JPA中这种方式查询会存在着屡次级联查询的问题,对性能有所影响,可是在通常的企业级应用当中,为了开发的便捷,这种性能牺牲通常来讲是能够接受的。

  特别的:在一对多中或者多对一中,即使是fetch为eager,也会先查询主对象,再查询关联对象,可是在eager的状况下虽然是有屡次查询问题,可是没有n+1问题,关联对象不会像n+1那样多查询n次,而仅仅是把关联对象一次性查询出来,所以,在企业级应用当中,访问量不大的状况下通常来讲没什么问题。

  补充一段题外话,关于Hibernate/JPA/Spring-Data-Jpa与MyBatis的区别联系,这种话题不少讨论,对于Hibernate/JPA/Spring-Data-Jpa,我我的而言基本上可以熟练使用,谈不上精通,对于mybatis,因为深刻阅读过几回它的源码,对mybatis的设计思想以及细化到具体的方法,属性,参数算是比较熟悉,也开发过一些mybatis的相关插件。对于这两个持久化框架,整体来讲的区别是,Hibernate系列的门槛相对较高,配置比较多,相对来讲难度要大一些,主要体如今各类关系的问题上,据我所知,不少人的理解其实并不深入,不少时候甚至配置得有必定的问题,可是优点也很明显,SQL自动生成,改数据库表结构仅仅须要调整几个注解就好了,在熟练使用的基础上相对来讲要便捷一点。对于mybatis来讲,门槛很低,真的很低,低到分分钟就能入门的程度,我我的最喜欢也是mybatis最吸引人的地方就是灵活,特别的灵活,可是修改数据库表结构以后须要调整的地方比较多,可是利用目前比较优秀的插件,对于单表操做也基本上可以达到和Hibernate差很少的境界(会稍微牺牲一点点性能),多表的状况下就要麻烦一点。性能方面的比较,因为我没作过测试,不太比如较,不过应该mybatis要稍微高一些,毕竟他的查询SQL可控一些(固然Hibernate也支持原生sql,可是对结果集的处理不够友好)。

  以后更新:Root对象还有一批fetch方法,这个目前我不多用,后面有时间再来更新。

  补充:单表分页能够传入分页对象,好比findByName(String name, new pageRequest(0, 10));