The role of Spring Data JPA.

The implementation of the Repository layer is provided on the basis of the JPA specification, allowing you to switch between different ORM frameworks without changing the code.

PS: We use a different ORM framework, the DAO layer to write business code will be slightly different, SPRINGDATAJPA is to solve this occurrence.

JPA (Java persistence API)
is the Java Persistence Specification proposed by Sun's official. It provides Java developers with an object/association mapping tool to manage relational data in Java applications. It has been developed primarily to simplify existing persistent development efforts and integrate ORM technology
End Hibernate, TopLink, and other ORM frameworks for each camp situation. JPA is developed on the basis of fully absorbing the existing hibernate, TopLink and other ORM frameworks, and has the advantages of ease of use and strong scalability.

ORM: Objects in a program are automatically persisted to a relational database by using metadata that describes the mappings between the object and the database. The essence is to convert data from one form to another.

Note: JPA is not a new ORM framework, it is only used to standardize the existing ORM technology, it does not replace existing hibernate and other ORM framework, instead, we will use the ORM framework when developing with JPA, Only applications developed at this time are not dependent on a persistence provider. Applications can be downloaded without modifying the code to run under any JPA environment, truly low-coupling, extensible programming. similar to JDBC, our program programmed for the database API of the feature before JDBC appeared, but now we only need to program the JDBC API to be able to switch to other databases without changing the code.

JPA is a set of specifications, not a set of products. Hibernate is a set of products that, if they implement the JPA specification, we can call them a JPA implementation product. With JPA, we can completely free our application from hibernate.

Spring Data JPA

The implementation of the repository layer is provided under the JPA specification , but it is up to you to decide which ORM to use. Although the ORM Framework implements the JPA specification, switching between different ORM frameworks still requires writing different code (business code for the Repository/dao layer), while using spring data JPA allows you to switch between different ORM frameworks without changing the code. And spring data JPA is a good package for the repository layer, and it saves a lot of hassle.

In the actual project, it is recommended to use Spring Data JPA + ORM (e.g. Hibernate) for development, which provides a way to switch between different ORM and makes repository simple. Low-coupling program.

MyBatis is not an ORM framework, MyBatis simply maps the contents of a database to entities. The entity is not mapped to a field in the database

Reprint: http://blog.csdn.net/benjaminlee1/article/details/53087351

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

What does Spring Data JPA mean by providing a Repository layer implementation?

The reason JPA was born is to integrate the third-party ORM framework to achieve the world of ORM, but it has not yet been fully realized.

So what is SPRING-DATA-JPA again? This place needs a little explanation, we do Java development know spring is strong, so far, enterprise application Spring is almost omnipotent, ubiquitous, is already the de facto standard, enterprise application does not use spring's almost no, so that's right. and spring's ability to integrate third-party frameworks is strong, and he's not just going to do the first IOC container as simple as this, but now spring is too broad, mainly in the integration with third-party tools. In the context of integration with third parties, Spring has done the work of persisting this piece, and my personal feeling is that spring wants to take the persistence of this piece of content as well. So there is spring-data this series of packages. Including, Spring-data-jpa,spring-data-template,spring-data-mongodb,spring-data-redis, and a folk product, mybatis-spring, like the front, This is a third-party package integrated with MyBatis, which is a dry persistence tool.

When using the persistence tool, there is usually an object to manipulate the database, in the native hibernate called the session, in the JPA called Entitymanager, in the MyBatis called Sqlsession, through this object to manipulate the database.

In DAO, there is the object above. So what are the features that the ORM framework itself provides? The answer is basic crud, all of the underlying CRUD frameworks are provided, we use it to feel very convenient, very strong, the business logic level of processing ORM is not provided , if the use of the native framework, business logic code we will generally customize, we will write the SQL statement, and then execute. At this time, thepower of SPRING-DATA-JPA is manifested, ORM provides the capabilities he has to offer, ORM Framework does not provide the business logic function SPRING-DATA-JPA also provides , all-round solution to the needs of users. In the process of developing with SPRING-DATA-JPA, we hardly need to write an SQL statement, at least in my opinion, enterprise applications can basically not write any SQL, of course, SPRING-DATA-JPA also provide their own way of writing SQL, This depends on how the individual chooses, all can.

How to do not write SQL statements?

For example: The two classes of our userrepository and Userrepositoryimpl are written as follows.

Public interface Userrepository extends Jparepository<user, Integer>{}public class Userrepositoryimpl {}

So why do you do this here? The reason: SPRING-DATA-JPA provides the underlying crud work, but also provides the functionality of the business logic (which is where the power of the framework is), so our repository interface does two things, The interface that inherits the underlying CRUD functionality provided by SPRING-DATA-JPA, such as the Jparepository interface, also needs to define its own method in the Userrepository interface, So the result is userrepository this interface has a lot of methods, then if our Userrepositoryimpl implementation of the Userrepository interface, the result is that we have to rewrite all the methods inside, This is the Java syntax of the provisions, so that the tragedy arose, Userrepositoryimpl inside we have a lot of @override methods, this is obviously not possible, the conclusion is, here we do not have to write implements part.

SPRING-DATA-JPA realizes the above ability, how does he realize it? Here we use source code to present his context, the process of cglib dynamic Agent played an outstanding role.

Inside the SPRING-DATA-JPA, there is a class called

public class simplejparepository<t, ID extends serializable> implements Jparepository<t, Id>        Jpaspecificationexecutor<t>

we can see that this class implements the Jparepository interface, in fact, if we follow the above configuration, there is userrepository under the same package, but there is no userrepositoryimpl this class, The implementation of this interface during runtime userrepository is the Simplejparepository interface above. And if there is userrepositoryimpl this file, then the Userrepository implementation class is Userrepositoryimpl, And Userrepositoryimpl This class is Simplejparepository sub-class, so that a good solution to the above without writing implements problem . We can find out by reading the source code of this class that it wraps the Entitymanager, the underlying call relationship or Entitymanager in the crud.

Reprint: https://www.cnblogs.com/dreamroute/p/5173896.html

The role of Spring Data JPA.