在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