First, the status description
Java persistence layer framework currently the most widely used ORM is JPA and Mybatis. Just a JPA ORM framework of norms to achieve this standard is more complete Spring Data JPA (Hibernate realize the underlying basis), is a Spring-based data persistence layer framework, which means that it can only be in the Spring environment. Mybatis is also an excellent data persistence layer framework that can better support ORM entity-relational mapping, dynamic SQL and so on.
The author in the process of learning these two frames, seen a lot of posts, whenever a post comparing the advantages and disadvantages of these two frameworks, would attract a controversy. From the author's point of view, why the domestic developers or development teams use less JPA? In order to avoid someone attacked me, I tend to do a bit of a domestic index search, this data can not fool people.
The blue line is Mybatis search volume, search volume JPA green. If you search for a foreign index, you will get a completely different result. So this is why? We have to start with the JPA features:
- JPA or for simple single-table SQL query very friendly and even can be very intelligent. He is ready for your persistence layer operation method that is used to a lot of use. Even just write an interface method such findByName, he will be able to help you perform intelligent look-up table data corresponding entity class by name, no need to write SQL.
- However, JPA for multi-table queries and the associated dynamic SQL, SQL and other custom very unfriendly. For JPA, the implementation is an implementation QueryDSL, the code implementation is below. I would like to ask: Do you want to use this instead of SQL code it?
JPAQueryFactory queryFactory = new JPAQueryFactory(em);
JPAQuery<Tuple> jpaQuery = queryFactory.select(QTCity.tCity,QTHotel.tHotel)
.from(QTCity.tCity)
.leftJoin(QTHotel.tHotel)
.on(QTHotel.tHotel.city.longValue().eq(QTCity.tCity.id.longValue()));
//添加查询条件
jpaQuery.where(predicate);
//拿到结果
return jpaQuery.fetch();Another method is to use NativeQuery, I still would like to ask: Do you want to write java code inside the SQL string with a way to fight it?
@Entity
@NamedNativeQueries(value={
@NamedNativeQuery(
name = "studentInfoById",
query = " SELECT * FROM student_info "
+ " WHERE stu_id = ? ",
resultClass = Student.class
)
})
@Table(name="student_info")This is part of the realization of the above does not take into dynamic SQL problem, considering the dynamic SQL, the wording would be more complicated. The so-called dynamic SQL is this: according to the parameters passed in different conditions, different configurations SQL , many articles comparing the two frameworks have ignored the problem of dynamic SQL, in this regard Mybatis better support. Mybatis write dynamic SQL in the final analysis SQL, rather than fight java code java code or string. Programmers particularly resistant to several things:
- The SQL complicated relationship written in the java code inside, fight string writing is not convenient
- SQL is the best expression of relational query languages entity, programmers do not want to use the SQL language of alienation.
- Programmers do not want to learn something not common, we will obviously SQL
- Although most of the operating JPA package up, but also very good use, but SQL tuning how to do?
You can use Spring-Data-JPA-extra solve the problem JPA fight string writing and SQL alienation. However, according to the author of usage, Spring-Data-JPA-extra is a personal project developer for the production is still immature, there are a lot of problems for multi-source data processing, complex types of treatment.
Second, Gresham's Law?
However, another school of thought, you see how other people overseas programmers with JPA? You do not learn something new, do not let others use? JPA very easy to use ah, the only drawback is the complexity associated with SQL support came close, but as long as you learn it also can support ah, what are you Gresham's Law. If after a well-designed entity-relationship model, JPA is clearly the optimal solution, SQL programmers to write really better JPA entity relationships according to the generated SQL. I want to say, this view is justified. However, I want to say is not a domestic programmers do not want to learn, but another reason.
- First of all, it works for many years in remote, more contact with foreign programmers. They are accustomed to using JPA's a reason, because the application is really too small for the size of their country, compared to domestic users of an application as compared to moving the millions, they are obviously more relaxed on the needs of database design and tuning .
- Application design abroad tend to be more concise, and domestic applications are often more functional. If you do not believe, you can go and see the work flow, what will, and what are the rollback process invented by us, they did not. You let them write one of our workflow application give it a try with JPA, vomiting tired they can not do.
- SQL code inside alienation or write SQL, increased learning costs and the cost to some extent. So few people use, with fewer people you have to meet the team most people.
Having the above points, Mybatis why are there so many domestic users and manufacturers use not difficult to understand. Mybatis may also be used, such as: Mybatis-plus or code generation to compensate for the lack of ease of use. JPA figure, married, everything is out of character, that face looks knock chen point difficult to handle social relations. Although Mybatis not excellent in all respects, the body also can be passable appearance, personality is also good. The key is to listen to what you say you are, and are willing to help him make-up friend. You say you want to choose which one?
Well, some people would say, what are you resent? No more than the number of foreign audiences, functional Internet application yet? I'm afraid it has more than domestic, this is a fact. But speaking from the ratio of domestic or more, the proportion of the developer decided to choose technology direction. This also led to a thinking, but they usually learn to use JPA training, so when writing large service application is also used JPA. Well, they write complex SQL JPA would write it? The answer is rarely used, and even some foreign companies to write banned associated with the query SQL. How to do that? Not associated with SQL how to develop business requirements? Nope.
Third, the service split or slightly Service
Now there are more and more domestic companies, was drop micro services, but very few really good business floor. This multi-table associated with the query What is the relationship? We first to achieve such a demand: Query belongs to all business data A B-related roles.
- If we develop the traditional single application, we may be the role of Table A and Table B business associate query, and then get the query results
- If we do is micro-services, we may be split into authority service A, B. Business Services A service interface to obtain access to go to the role of flag information, then the information to the business service interface to obtain B business data based on roles flag.
So some people will say, access to two interfaces must be slower than accessing an interface of it! This really is not, if we do micro-services, applications must be our size and the amount of data to reach a certain level. We will certainly consider the points table and warehouses, load balancing, splitting refined service and other issues, when more applications are distributed development mode, multi-table queries associated with the use of the less opportunity. Service after splitting due to the single function, load shunt and other reasons, access speeds are often centrally stored data is larger than the amount of data, much faster and more services will be centralized application deployment.
The problem is back, not associated with how SQL development process? Overall service is split by a reasonable, rational design of organizational relationships of the application interface data, the team has a good landing micro-services experience, can be achieved without the use of SQL query associated with application development. As we all know, NOSQL more and more popular, most of NOSQL databases are no so-called relationship.
Fourth, the frame selection comparison
| Comparison items | Spring Data JPA | Mybatis |
|---|---|---|
| Single-table operation | Just succession, the code is extremely rare and very convenient. And support the method name with the keyword generated SQL | Code generation tool may be used or Mybatis-Plus and other tools, is also very convenient, but relatively weaker JPA. |
| Multi-table associated with the query | Not very friendly, not convenient enough to use dynamic SQL, and SQL and code coupled together | Friendly and can have a very intuitive dynamic SQL |
| Custom SQL | SQL to write notes, and write some strenuous dynamic SQL | SQL can be written in XML which is to write dynamic SQL syntax weapon. Annotations also supports SQL. |
| Learning costs | Slightly higher | Lower write basic SQL will use |
To summarize the author's point of view:
- If you are self development, "small is beautiful" applications, it is recommended that you use JPA
- If you are a developer of large and enterprise applications, of course, technology selection to follow the team. The selection of technology in the country is usually Mybatis.
If your company's management is very standard, micro landing service experience is very mature, consider using JPA in a team project. With little or no associated query.
Look forward to your attention
- Blogger recently wrote a book: "hand touch hand to teach you to learn SpringBoot series chapter 97 section -16"
This article is reproduced indicate the source (en must not turn only the text): letters Gebo off .