spring-data-jpa

本篇進行Spring-data-jpa的介紹，幾乎涵蓋該框架的全部方面，在平常的開發當中，基本上能知足全部需求。這裏不講解JPA和Spring-data-jpa單獨使用，全部的內容都是在和Spring整合的環境中實現。若是須要了解該框架的入門，百度一下，不少入門的介紹。在這篇文章的接下來一篇，會有一個系列來說解mybatis，這個系列從mybatis的入門開始，到基本使用，和spring整合，和第三方插件整合，緩存，插件，最後會持續到mybatis的架構，源碼解釋，重點會介紹幾個重要的設計模式，這樣一個體系。基本上講完以後，mybatis在你面前就沒有了祕密，你能解決mybatis的幾乎全部問題，而且在開發過程當中至關的方便，得心應手。

這篇文章因爲介紹的類容很全，所以很長，若是你須要，那麼能夠耐心的看完，本人經歷了很長時間的學識，使用，研究的心血濃縮成爲這麼短短的一篇博客。

大體整理一個提綱：

　　一、Spring-data-jpa的基本介紹；

　　二、和Spring整合；

　　三、基本的使用方式；

　　四、複雜查詢，包括多表關聯，分頁，排序等；

如今開始：

　　一、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));