Shulou(Shulou.com)06/03 Report--

This article focuses on "what are the differences between Hibernate, JPA, Mybatis, JOOQ and JDBC Template". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "what are the differences between Hibernate, JPA, Mybatis, JOOQ and JDBC Template?"

I. SQL package and performance

When using Hibernate, we query the POJO entity class instead of the database table, such as the hql statement select count (*) from User, where the User is a Java class, not the database table User. This is in line with the original ideal of ORM. ORM believes that there is a huge gap between Java programmers' way of thinking using OO and that of relational databases. In order to fill the gap between object and relational thinking, it is necessary to do an object-to-relational mapping. Then in the object world of Java, programmers can use pure object thinking to query POJO objects under the condition of object attributes. There is no need to have any concepts of tables, fields, and other relationships, so it is easier for java programmers to do persistence layer operations.

JPA can be regarded as the son of Hibernate, but also inherited this idea, completely encapsulated SQL, so that Java programmers can not see the concept of relations, with pure object-oriented thinking, re-create a new query language to replace sql, such as hql, JPQL and so on. Frameworks that support JPA, such as Ebean, belong to this type of framework.

But can encapsulating SQL and using another pure object-oriented query language instead of sql really make it easier for programmers to implement persistence layer operations? The popularity of MyBatis proves that this is not the case, at least in most cases, using hql is no easier than using sql. First of all, in many ways, languages such as hql/JPQL are more complex and difficult to understand; the second is significant performance degradation, slower speed, huge memory footprint, and difficult to optimize. The most annoying thing is that when the concept of relationship is replaced with the concept of object, the query language becomes less flexible and much less expressive than sql. There are a variety of restrictions when writing query statements. A typical example is a multi-table association query.

Whether hibernate or jpa, join queries between tables are mapped to associations between entity classes, so that if there is no association between two entity classes, you cannot join two entities (or tables) to query. This is very annoying, because most of the time, we don't need to explicitly define the relationship between two entity classes to implement business logic, if we use hql, we have to add code between two entity classes just for join, and we can't reverse engineer, if there are no foreign key constraints defined in the table, reverse engineering will erase the association code we added.

MyBatis is another type of persistence framework, which does not encapsulate SQL or create a new query language for face objects, but directly uses SQL as the query language and just fills the results into POJO objects. Using sql is not more difficult than hql and JPQL, and it is fast to query. You can use any complex query flexibly as long as the database supports it. From the perspective of SQL encapsulation, MyBatis is more successful than Hibernate and JPA. SQL should not be encapsulated and hidden, making it easier for Java programmers to learn and use SQL, which should be an important reason for the popularity of MyBatis.

The lightweight persistence layer framework JOOQ, like MyBatis, directly uses SQL as the query language. Although it is much less well-known than MyBatis,JOOQ, JOOQ can not only take advantage of the flexibility and efficiency of SQL as MyBatis, but through reverse engineering, JOOQ can also write SQL statements in Java code, using the automatic completion function of IDE code to automatically prompt table names and field names, thus reducing the programmer's memory burden. A compilation error can also occur when the metadata changes, prompting the programmer to modify the corresponding SQL statement.

Ebean, as a JPA-based framework, also uses the JPQL language for queries, which is annoying in most cases. But it is said that Ebean does not exclude SQL, you can query directly with SQL, or you can construct SQL statements (or JPQL statements) in your code in a DSL way similar to JOOQ? But have not used Ebean, so the details are not clear.

Needless to say, JDBC Template doesn't do ORM at all. It's a pure SQL query, of course. Using the Spring framework, you can combine JDBC Template and JPA to use JDBC in places where JPA is not easy to query, or where inefficiency is not good to optimize, alleviating the trouble caused by Hibernate/JPA encapsulating SQL, but I still do not see the necessity of encapsulating SQL, except for bringing programmers a lot of trouble and learning burden, without obvious benefits.

II. DSL and adaptability to change

In order to achieve complex business logic, whether using SQL or hql or JPQL, we have to write a lot of simple or complex query statements, ORM can not reduce this part of the work, at most is to use another object-oriented style language to express query requirements, as mentioned earlier, using object-oriented style language is not necessarily easier than SQL. Usually, there are many tables in the business system, and each table has many fields. Even writing the simplest query statement is not an easy task. It is necessary to remember which tables, fields and functions are in the database. Writing queries is often a headache.

QueryDSL, JOOQ, Ebean and even MyBatis and JPA all design features to help developers write queries, which some call "DSL-style database programming." QueryDSL may be the first to realize this kind of function, reverse engineering the table structure of the database into java classes, and then enable java programmers to construct a complex query statement with the syntax of java. Using the automatic completion function of IDE code, it can automatically prompt table names, field names, keywords of query statements, etc., which successfully simplifies the writing of query statements. It frees the programmer from the burden of memorizing various names, functions and keywords.

There are many versions of QueryDSL, but much of it is QueryDSL JPA, which can help developers write JPQL statements, which, as mentioned earlier, have many limitations that are not as flexible and efficient as SQL. Later, JOOQ and Ebean basically inherited the idea of QueryDSL. Ebean is basically a JPA-style ORM framework. Although it also supports SQL, it is not clear whether its DSL feature supports the writing of SQL statements. The examples seen on the official website are used to construct JPQL statements.

The most successful one is JOOQ. Unlike QueryDSL, JOOQ's DSL programming helps developers write SQL statements, abandoning the cumbersome concept of ORM. JOOQ is very light and easy to learn and use. At the same time, the performance is very good. Unlike QueryDSL and Ebean, you need to understand complex JPA concepts and various strange limitations. JOOQ writes ordinary SQL statements. Just populate the query results into the entity class (strictly speaking, JOOQ does not have an entity class, only automatically generated Record objects), JOOQ does not even have to convert the results into entity classes, which allows developers to obtain the value of the results according to the field, which is easier to use than JDBC relative to JDBC,JOOQ will convert the result value to the appropriate Java type.

Traditional mainstream frameworks have little support for DSL style, and there are basically no such features in Hibernate. MyBatis provides a "SQL statement builder" to help developers construct SQL statements, but it is much different from QueryDSL/JOOQ/Ebean in that it cannot prompt table and field names, and the syntax is not like SQL.

JPA gives people the impression that it is complex and difficult to understand, and its MetaModel Api inherits the characteristics. MetaModel API+Criteria API, coupled with Hibernate JPA 2 Metamodel Generator, makes people feel a bit like QueryDSL JPA, only around a big bend, superimposed several layers of technology, and finally barely realizes the easy-to-understand function of QueryDSL JPA. Many people do not recommend the use of JPA+QueryDSL, but recommend the use of JPA MetaModel API+Criteria API+Hibernate JPA 2 Metamodel Generator, which is difficult to understand, perhaps because it is a pure standard JPA scheme.

Another main selling point of database DSL programming is strong adaptability to change. Database table structure usually changes frequently in the process of development. In traditional non-DSL programming, the field name is just a string. If the field name or type changes, the query statement is not modified accordingly, the compilation will not make an error, and it is easy to be ignored by developers, which is a main source of bug. In DSL programming, the field is reverse-engineered as an attribute of a java class. After the database structure is changed, the query statement as part of the java code will have compilation errors, prompting developers to modify it, which can reduce a lot of bug, reduce the burden of testing, and improve the reliability and quality of the software.

III. Transplant across databases

Hibernate and JPA use database-independent intermediate languages like hql and JPQL to describe queries, which can be seamlessly ported to different databases. Porting to a database with a huge difference in SQL usually requires little or no code modification. If Ebean is developed using JPA instead of native SQL, it can be smoothly migrated to different databases.

MyBatis and JOOQ use SQL directly, and it is inevitable to modify SQL statements when migrating across databases. MyBatis is relatively poor in this respect, with only one feature provided by dynamic SQL, which writes different sql statements for different databases.

Although JOOQ cannot be seamlessly portable like Hibernate and JPA, it is much better than MyBatis. A large part of the DSL of JOOQ is universal, for example, in paging queries, the limit/offset keyword of Mysql is a very convenient way to describe, but the SQL of Oracle and SQLServer does not support it. If we use the limit and offset methods of DSL of JOOQ to construct SQL statements without modification and transplantation to Oracle and SQLServer that do not support limit/offset, we will find that these statements can be used normally, because JOOQ will convert limit/offset into equivalent SQL statements of the target database. According to the characteristics of the target database conversion SQL statement, JOOQ only needs to modify a little code when transplanting between different databases, which is obviously better than MyBatis.

JDBC Template should be the worst, and you can only try to use standard sql statements to reduce migration effort.

IV. Security

Generally speaking, stitching query statements have security risks and are easy to be attacked by sql injection. Whether it is jdbc or hql/JPQL, it is not safe to use concatenated query statements. For JDBC, using parameterized sql statements instead of concatenation can solve the problem. JPA should use Criteria API to solve this problem.

DSL-style frameworks such as JOOQ will eventually be parameterized by render as sql, which is inherently immune to sql injection attacks. Ebean also supports DSL programming and is also immune to sql injection attacks.

This is because DSL-style programming parameterized queries are easier than concatenated string queries, and no one can concatenate strings. While jdbc/hql/JPQL concatenation strings are sometimes simpler than parameterized queries, especially jdbc, many people are lazy to use unsafe ways.

5. The failures of JOOQ

Most people may disagree that although Hibernate and JPA are still popular and are the most mainstream persistence frameworks, the pure ORM encapsulating SQL is out of date, and the benefits are lower than the cost of using them and should be eliminated. Although MyBatis has many advantages, its advantages JOOQ basically has, and most of them are better. The biggest disadvantage of MyBatis is that it is difficult to avoid writing xml files, xml files are difficult to write, easy to make mistakes, and it is not easy to find errors. There is no advantage over JOOQ,MyBatis in most cases.

Ebean has the advantages of many different frameworks at the same time, but it is based on JPA and inevitably has various limitations of JPA, which is a fatal disadvantage.

JOOQ this extremely lightweight framework is technically the most perfect, suddenly one day several Web systems collapsed at the same time, and finally found that the trial period of JOOQ expired, this is the failure of JOOQ, it is not completely free, only free for open source databases such as MySql.

Finally, I decided to choose JDBC Template.

At this point, I believe you have a deeper understanding of "what are the differences between Hibernate, JPA, Mybatis, JOOQ and JDBC Template". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.