Advantages and disadvantages of Hibernate

Hibernate is an open-source object relationship ing framework that encapsulates JDBC objects in a lightweight manner, so that Java programmers can use the object programming thinking to manipulate the database as they wish.

Hibernate can be used in any scenario where JDBC is used. It can be used in both Java client programs and Servlet/JSP Web applications. The most revolutionary thing is that, hibernate can replace CMP in the J2EE architecture of application EJB to fulfill the task of data persistence.

Most development organizations often create independent data persistence layers. Once the underlying data structure changes, it will be very costly to modify the rest of the application to adapt to this change. Hibernate fills this gap in time and provides an easy-to-use and efficient object relationship ing framework for Java applications. Hibernate is a lightweight persistence framework with rich functions.

Advantages:

A. Hibernate uses the Java reflection mechanism instead of the bytecode enhancement program to achieve transparency.

B. Hibernate has excellent performance because it is a lightweight framework. The flexibility of ing is excellent.

C. It supports various relational databases, from one-to-one to many-to-many complex relationships.

Disadvantage: it limits the object model you are using. (For example, a persistence class cannot be mapped to multiple tables.) its unique interface and poor market share are also disturbing. However, hibernate also mitigated these risks with its powerful development momentum. Other open-source Persistence frameworks also have some, but none of them have the market impact such as Hibernate.

I am a little excited and hope to understand that I don't feel unhappy because someone has criticized Hibernate, but because the opinions in the post really make me feel ridiculous. No matter whether Hibernate is good or not, I only feel sorry that I cannot find a real high-level comment on Hibernate in the Chinese forum. There is a hot thread about Hibernate on TSS, which has been followed by several hundred posts, including the CTO of Hibernate authors Gavin and LiDO JDO. There have been some heated debates on JDO and Hibernate, I have patiently read it once and still have not found any really powerful attacks against Hibernate. The so-called attacks are nothing more than a configuration tool for Hibernate without the support of commercial companies, there is no such reason as standardization.

My comments are as follows:

1. Hibernate is a lightweight JDBC object encapsulation. It is an independent object persistence layer framework and has no necessary connection with App Server and EJB. Hibernate can be used in any situations where JDBC can be used, such as the database access code of Java applications, the implementation class of DAO interfaces, and even the code for accessing the database in BMP. In this sense, Hibernate and EB are neither a category nor a relationship between them.

2. Hibernate is a framework closely related to JDBC, so the compatibility of Hibernate and the JDBC driver have a certain relationship with the database, but it is related to the Java program that uses it, it has nothing to do with the App Server, and there is no compatibility problem.

3. Hibernate cannot be used directly to compare with Entity Bean. It can be compared only in the framework of the entire J2EE project. In addition, even in the overall framework of the software, Hibernate emerged as a replacement for JDBC, rather than an alternative to Entity Bean. Let me repeat the framework structure that I have already listed n times:

Traditional Architecture:

1) Session Bean <-> Entity Bean <-> DB

Alternative architecture to solve performance barriers:

2) Session Bean <-> DAO <-> JDBC <-> DB

Use Hibernate to improve the development efficiency of the above architecture:

3) Session Bean <-> DAO <-> Hibernate <-> DB

Analyze the above three architectures:

1. memory consumption: JDBC architecture 2 is undoubtedly the most memory-saving, Hibernate architecture 3 is the second, and EB architecture 1 is the worst.

2. Operational Efficiency: If JDBC code writing is very optimized, the JDBC architecture runs most efficiently, but in actual projects, this is almost impossible. This requires programmers to be very proficient in JDBC, use the Batch statement to adjust parameters such as the Batch Size and Fetch Size of the PreapredStatement, and use the result set cache when necessary. In general, programmers cannot do this. Therefore, the Hibernate architecture shows the fastest running efficiency. EB's architecture efficiency will be very poor.

3. Development efficiency: with the support of JBuilder and simple projects, EB architecture has the highest development efficiency, followed by JDBC, and Hibernate has the worst. However, in large projects, especially when the persistent layer relationship ing is complex, Hibernate is highly efficient, followed by JDBC, and EB architecture is likely to fail.

4. distributed, security check, cluster, and Server Load balancer support

Because there is SB as a Facade, there is no difference between the three architectures.

4. Where are the learning difficulties of EB and Hibernate?

Where is EB difficult? Rather than complex XML configuration files, EB may suffer from severe performance barriers due to a slight carelessness. Therefore, it is difficult for you to learn a lot of EJB Design Patterns to avoid performance problems. You need to learn the configuration of App Server and EB to optimize the running efficiency of EB. For EB development, most of the programmer's energy has been put on EB's performance problems, instead, you can focus more on the design of the Object persistence layer.

What is the difficulty of Hibernate? Not the complexity of Hibernate itself. In fact, Hibernate is very simple, and it is difficult to be too flexible in Hibernate.

When you use EB to implement the persistent layer, you will find that EB is too clumsy, so you have no choice at all, so you don't have to spend any energy designing a solution, balancing the quality of the solution, and worrying about which solution to choose, because only the only solution is in front of you. You can only do this, no choice.

On the contrary, Hibernate is too flexible. You can design at least a dozen solutions to solve the same problem, so it is especially difficult to use it? What are the differences between these solutions? What are their operating principles? Which one is more efficient? If you generate a primary key, there are seven or eight solutions for you to choose from? Set, List, and Bag can be used for Set attributes. Which efficiency is high? Iterator can be used for queries, list can be used, which is better, what is the difference? Are you embarrassed? You can configure the composite primary key directly in hbm or customize the CustomerType. Which one is better? Are you embarrassed? For a table, you can select a single ing object, or map it to a parent-child object, or two objects. Which solution is better, are you embarrassed?

This list can be listed until you don't want to see it again. When there are countless dazzling solutions in front of you, will you feel happy? Or sad? If you are a responsible programmer, you will certainly carefully study the differences between each solution, the efficiency of each solution, and the application scenarios of each solution, you will feel that you are already in and cannot be pulled out. If you use EB, you have made the decision in the first second, and you have no choice at all. For example, you can only use Collection for set attributes. If it is Hibernate, you will be in the Bag, there is no way to write a List or Set.