How to choose the persistence layer framework JPA and Mybatis

How to choose the persistence layer framework JPA and Mybatis

1. Status quo description

At present, the most widely used Java persistence layer ORM framework is JPA and Mybatis. JPA is just an ORM framework specification. The complete implementation of this specification is Spring Data JPA (the bottom layer is implemented based on Hibernate), which is a Spring-based data persistence layer framework, which means it can only be used in the Spring environment. Mybatis is also an excellent data persistence layer framework, which can better support ORM entity relationship mapping, dynamic SQL, etc.

In the process of learning these two frameworks, the author has read many posts. Whenever there is a post comparing the advantages and disadvantages of these two frameworks, a controversy arises. From the author's point of view, why do domestic developers or development teams seldom use JPA? In order to avoid someone attacking me, I deliberately did a domestic index search. This data can't deceive people.

The blue line in the figure is Mybatis search volume, and the green is JPA search volume. If you change a foreign search index, you will get a completely different result. So why is this? We also start with the characteristics of JPA:

  • JPA is very friendly to single-table or simple SQL queries, and it can even be said to be very smart. He has prepared a large number of out-of-the-box persistence layer operation methods for you. Even as long as you write an interface method like findByName, he can intelligently help you find the table data corresponding to the entity class based on the name, without writing SQL at all.
  • However, JPA is very unfriendly to multi-table related queries, dynamic SQL, custom SQL, etc. For JPA, one implementation is QueryDSL, and the implemented code is as follows. I want to ask: Do you want to replace SQL with such code?

JPAQueryFactory queryFactory = new JPAQueryFactory(em);
JPAQuery<Tuple> jpaQuery =,QTHotel.tHotel)
return jpaQuery.fetch(); 

Another way is to use NativeQuery. I still want to ask: Do you want to write SQL in the java code by spelling strings?

                name = "studentInfoById",
                query = " SELECT * FROM student_info " 
                      + " WHERE stu_id = ? ",
                resultClass = Student.class

The above part of the implementation has not considered the issue of dynamic SQL. If you consider the dynamic SQL, the writing will be more complicated. The so-called dynamic SQL is: construct different SQL according to the different input parameter conditions . Many articles comparing these two frameworks ignore the problem of dynamic SQL. In this regard, Mybatis supports better. The dynamic SQL written by Mybatis is SQL after all, not java code or java code spelling strings. The programmer specifically rejects a few things:

  • Write complex relational SQL in java code, it is not convenient to write string
  • SQL is the language most capable of expressing entity relationship queries, and programmers do not want to use the alienated SQL language.
  • Programmers don t want to learn things that are not universal. Obviously everyone knows SQL.
  • Although JPA encapsulates most of the operations, it is quite easy to use, but how to do SQL tuning?

You can use Spring-Data-JPA-extra to solve the problems of JPA spelling and SQL alienation. However, according to the author's usage, Spring-Data-JPA-extra is a personal developer project, which is still immature for production, and there are still many problems with multi-data source processing and complex type processing.

2. Bad money drives out good money?

However, there is another point of view. Why do foreign programmers use JPA? Don t you learn new things and don t let others use them? JPA is very convenient to use. The only drawback is that the complex associated SQL is almost supported, but as long as you learn it, you can still support it. You are bad money driving out good money. If a good entity relationship model is designed, JPA is obviously the optimal solution, and the SQL written by programmers is really not as good as the SQL generated by JPA based on entity relationships. The author would like to say that this view is also reasonable. However, I want to say that it is not that domestic programmers are unwilling to learn, but that there are other reasons.

  • First of all, the author has been working remotely for many years and has had more contact with foreign programmers. One of the reasons why they are used to using JPA is really because their country s application scale is too small. Compared with a domestic application with millions of users, they are obviously more calm about the needs of database design and tuning. .
  • Foreign application designs are often more concise, while domestic application requirements are often more functional. If you don t believe it, you can go and take a look at the workflow. We invented all countersignatures, process rollbacks, and so on. They didn t. If you ask them to write a workflow application of ours using JPA, they can't do it even if they are tired of vomiting blood.
  • Alienated SQL or writing SQL in the code increases the cost of learning and usage to a certain extent. So if you use fewer people, you have to accommodate most of the people in your team.

Having said the above points, it is not difficult to understand why Mybatis has so many users and manufacturers in China. Mybatis can also use such as: Mybatis-plus or automatic code generation to make up for the lack of ease of use. JPA's body, family, and personality are all full marks, but his face is stubborn and difficult to handle social relationships. Although Mybatis is not excellent in every aspect, the figure is decent, the appearance is fair, and the personality is also good. The key is to listen to you what you say, and friends who are willing to help him make-up. Want you to say which one do you choose?

So, some people will say, are you arrogant? Are there any Internet applications with large audiences and strong functions in foreign countries? I'm afraid it's more than that in China. This is also true. But in terms of proportion, it is still more domestic, and the proportion determines the direction of developers' choice of technology. This has also led to an inertial thinking. They usually use JPA for learning and training, so they also use JPA when writing large-scale service applications. So, do they write complex SQL when they write JPA? The answer is that it is rarely used, and even some foreign companies explicitly prohibit writing related query SQL. What to do then? How to develop business requirements without associated SQL? Nope.

3. service split or microservices

There are also more and more companies in China that are implementing microservices, but there are very few companies that really do better. What does this have to do with multi-table related queries? Let's first implement such a requirement: query all business B data related to role A.

  • If we are developing a traditional monolithic application, we may perform an associated query between role table A and business table B, and then get the query result
  • If we are doing microservices, we may be split into permission service A and business service B. First go to the A service interface to obtain the role identification information, and then go to the business service B interface to obtain the business data according to the role identification information.

Then some people will say that accessing two interfaces must be slower than accessing one interface! This is really not. If we do microservices, our application scale and data volume must have reached a certain level. It will also consider issues such as table and database sub-database, load balancing, and service split and refinement. When the distributed development method is applied more, the chance of multi-table related queries will be less. Due to the single function, load distribution and other reasons of the split service, the access speed is often much faster than that of the centralized storage of large amounts of data and the centralized deployment of multiple services.

The question is back, how to develop a program without associated SQL? In general, through reasonable service splitting and reasonable design of the organizational relationship of application interface data, the team has relatively good experience in microservice implementation, and it is possible to develop applications without using associated query SQL. Everyone knows that NOSQL is becoming more and more popular, and most NOSQL databases have no so-called association relationship.

4. frame comparison and selection

Summarize the author's point of view:

  • If you are developing a "small and beautiful" application by yourself, it is recommended that you use JPA
  • If you are developing large and comprehensive enterprise-level applications, of course you must follow the team's technical selection. This technology selection is usually Mybatis in China.
  • If your company's management is very standardized and the microservices landing experience is also very mature, you can consider using JPA in team projects. Use less or no associated queries.

Looking forward to your attention