Spring Data JPA 的做用.

在JPA規範基礎下提供了 Repository 層的實現 , 可以方便你們在不一樣的ORM框架之間進行切換而不要更改代碼 .

PS : 咱們用不一樣的ORM框架 , 在DAO層寫業務代碼會稍微有差別 , SpringDataJPA 就是爲了解決這個出現的.

JPA(Java Persistence API)
是Sun官方提出的Java持久化規範。它爲Java開發人員提供了一種對象/關聯映射工具來管理Java應用中的關係數據。它的出現主要是爲了簡化現有的持久化開發工做和整合ORM技術
結束Hibernate、TopLink等ORM框架各自爲營的局面。JPA是在充分吸取了現有Hibernate、TopLink等ORM框架的基礎上發展起來的，具備易於使用，伸縮性強等優勢。

ORM：經過使用描述對象和數據庫之間映射的元數據，將程序中的對象自動持久化到關係數據庫中。本質就是將數據從一種形式轉換到另一種形式。

注意: JPA不是一種新的ORM框架，它的出現只是用於規範現有的ORM技術，它不能取代現有的Hibernate等ORM框架，相反，採用JPA開發時，咱們仍將使用這些ORM框架，只是此時開發出來的應用不在依賴於某個持久化提供商。應用能夠在不修改代碼的狀況下載任何JPA環境下運行，真正作到低耦合，可擴展的程序設計。相似於JDBC，在JDBC出現之前，咱們的程序針對特性的數據庫API進行編程，可是如今咱們只須要針對JDBC API編程，這樣可以在不改變代碼的狀況下就能換成其餘的數據庫。

JPA是一套規範，不是一套產品。Hibernate是一套產品，若是這些產品實現了JPA規範，那麼咱們能夠叫它們爲JPA的實現產品。使用JPA，就能夠把咱們的應用徹底從Hibernate中解脫出來

Spring Data JPA

在JPA規範下提供了Repository層的實現，可是使用哪種ORM須要你來決定。雖然ORM框架都實現了JPA規範，可是在不一樣的ORM框架之間切換仍然須要編寫不一樣的代碼 ( Repository/Dao 層的業務代碼 )，而經過使用Spring data jpa可以方便你們在不一樣的ORM框架之間進行切換而不要更改代碼。而且spring data jpa 對Repository層封裝的很好，也省去了很多的麻煩。

在實際的工程中，推薦採用Spring Data JPA + ORM(如：Hibernate)進行開發，這樣在切換不一樣的ORM提供了方面，同時也使得Repository變得簡單。程序低耦合。

MyBatis不是ORM框架，MyBatis只是將數據庫中的內容映射爲實體。沒有將實體映射爲數據庫中的字段

轉載 : http://blog.csdn.net/benjaminlee1/article/details/53087351

　　   https://stackoverflow.com/questions/16148188/spring-data-jpa-versus-jpa-whats-the-difference

---

Spring Data JPA 提供 Repository 層實現是什麼意思 ? 

JPA誕生的原因是爲了整合第三方ORM框架,實現ORM的天下歸一,可是還沒能徹底實現 .

那麼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整合的第三方包，這些都是乾的持久化工具乾的事兒。

在使用持久化工具的時候，通常都有一個對象來操做數據庫，在原生的Hibernate中叫作Session，在JPA中叫作EntityManager，在MyBatis中叫作SqlSession，經過這個對象來操做數據庫.

在Dao中，就存在着上面的對象。那麼ORM框架自己提供的功能有什麼呢？答案是基本的CRUD，全部的基礎CRUD框架都提供，咱們使用起來感受很方便，很給力，業務邏輯層面的處理ORM是沒有提供的，若是使用原生的框架，業務邏輯代碼咱們通常會自定義，會本身去寫SQL語句，而後執行。在這個時候，Spring-data-jpa的威力就體現出來了，ORM提供的能力他都提供，ORM框架沒有提供的業務邏輯功能Spring-data-jpa也提供，全方位的解決用戶的需求。使用Spring-data-jpa進行開發的過程當中，經常使用的功能，咱們幾乎不須要寫一條sql語句，至少在我看來，企業級應用基本上能夠不用寫任何一條sql，固然spring-data-jpa也提供本身寫sql的方式，這個就看我的怎麼選擇，均可以。

怎麼作到不寫sql語句的 ?

好比 : 咱們的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。

轉載 : https://www.cnblogs.com/dreamroute/p/5173896.html