Why study Hibernate?

In the process of many projects I have done, I have been plagued by an outstanding problem, that is, the development of the persistent layer. In general, the development of the persistence layer either uses CMP or JDBC + DAO. CMP is not required. It is a failure practice for me, and JDBC + DAO also has many difficulties, it is difficult for me to fully map the records of the relational tables to the relationships of persistent objects. This is mainly because the relations of multiple tables cannot be directly mapped to the Mappings of persistent objects, A table may map multiple persistent objects, multiple tables may map one persistent object, and some fields of the table may map to a persistent object, however, some other fields are mapped to other persistent objects. Even if all these problems are well handled, you cannot directly program the Persistent Object (PO) as an object, because 1: the query of persistent objects in the N relationship is actually one or more SQL queries to the database. I once failed to design the persistence layer, the result is that a PO-1 query that associates many other persistent objects is a 5n + 1 SQL statement, which is extremely slow. At last, we had to modify the underlying design, and finally completely abandon the object design, perform operations based on the table fields.

However, it is very uncomfortable to do this because the system design is from the demand design, the system design is under the top, and the results are all in the detailed design stage, which is restricted by the persistent layer ing problem, I had to modify the design scheme from the bottom up and back to the old way of programming by process, which was very bad.

I have been thinking about this for a long time and finally realized that this is actually a classic problem: the ing between objects and relationships. In fact, this problem exists since the popularity of OOP programming, so some people have proposed to redesign the relational database and switch to the object database, but in fact the relational database has not been eliminated, therefore, you can only find a solution at the upper application layer. At this time, I understand that what I need is actually an ORM product.

My earliest thought of ORM was JDO. So I downloaded two JDO products and prepared to study them carefully. However, after some research, I found that I was very disappointed with JDO, the reason is as follows:

1. JDO does not have a good open-source implementation free of charge. Good products are commercial products, and there is no sales or technical support in China. This causes JDO to be used only for learning and cannot be used in actual projects. Otherwise, when you sell the software to the customer, you need to tell it, if you want to purchase another foreign software product without technical support in China and have a persistent layer problem, we cannot solve it. Please make an international long distance to solve the problem, do you think the customer can agree?

2. JDO is not a lightweight package. It tries to build a complete persistent layer framework, but it is still not perfect. It makes JDO feel heavy and many operations seem cumbersome and odd. This increases the programmer's learning and programming burden, and too many packages will cause a serious problem: once an error message is reported, debugging is very difficult, it is difficult for you to accurately locate the cause of the error. The lighter the encapsulation, the easier the problem is to locate and solve the problem. The heavier the encapsulation, the more complicated the problem is, CMP is a good example. If an error occurs, debugging is very difficult and troublesome.

3. JDO standards are not perfect and there are major defects. The main problem is that the PO cannot be separated from the PM (equivalent to the Hibernate Session), which is a very serious problem. It will cause a large number of VO copy operations during programming, which is very cumbersome; another major defect is the static POJO Enhancer, which does not support dynamic Enhance during runtime and does not support incremental compilation and debugging. Programming and debugging are very cumbersome, each time, you need to run a tool to Enhance POJO. In addition, there are some defects, such as imperfect JDOQL and insufficient ing relationship expressions.

4. Split the JDO product. This problem is also serious. Due to the defects of the JDO1.0 standard, the JDO2.0 standard is still far away, and in order to stand out from the competition, in addition to ease of operation and performance improvement, to attract customers, you must have your own product features. Then the defects of the 1.0 standard are just a stage for them to play, and each vendor will have its own unique solution to solve the defects of the standard, but this has caused the de facto split of JDO products. To what extent is this split serious? Let me give you a simple example: The POJO you have written can use a JDO Enhancer to Enhance the obtained PO and cannot run on another JDO product. This is similar to the Unix split in the past. The result is binary code-level incompatibility, but it can only be compatible at the C source code level. Currently, JDO has such a trend. Just like the difference between App Server and Weblogic, you must reconfigure an EJB developed on Weblogic and port it to Websphere.

The ORM in my mind has the following features:

1. open-source and free License. I can study the source code, rewrite the source code, and customize functions as needed.

2. Lightweight encapsulation, avoiding the introduction of too many complicated problems, easy debugging, and reducing the burden on programmers.

3. scalability and open APIs. When the functions are insufficient, you can expand the code by yourself.

4. Active developers and stable product development.

After abandoning JDO, I ruled out TopLink, CocoBase, Castor and so on based on the above principles, and finally chose Apache OJB and Hibernate.

The exclusion of OJB is easy to make. First, because its documentation is too simple and too few; second, because OJB plans to support JDO in the next version, its API will change significantly, so it is an error to learn about OJB at this stage. It will not be too late to learn after its API is stable.

The discovery of Hibernate is very accidental, but it was mentioned in the product mentioned by others, but after I started to study Hibernate, I found that I finally found my dream ORM.

Hibernate fully complies with the standards I mentioned above and solves all JDO defects. the elegance of the method is amazing. The Hibernate documentation is also very distinctive. It is not just a simple introduction to the functions of Hibernate, but is actually a summary of the best practices of a persistence layer design. Examples in this document are as follows, the summary in this document is the crystallization of the best design. I read Hibernate seriously. Not only does Hibernate have to be mastered, but I have a long experience in designing the persistence layer, in the past, I never thought that there was so much learning about the design of the persistent layer, and Gavin was definitely a great guy.

Of course, the most reusable reason for choosing Hibernate is that Hibernate is a software that I can fully control. Hibernate has very few source codes and is very concise. I always think it is quite strange. It is a miracle that so few source codes can implement so many functions. The source code tree of Hibernate is very clear and simple, and the source code is very easy to read. Once I encounter a problem that is not mentioned in the document, or a problem that is not clearly identified in the document, I went to the source code to find out all the problems, and made me very clear about the running principle and details of Hibernate, as if Hibernate was just like the code I wrote, it is clear that how to write a program can make Hibernate run with the highest efficiency, the most memory-saving, and the program has an error. It is clear that the problem is located and how to solve it. So using Hibernate gives me a lot of peace of mind that I can control it. Unlike those software that is too complicated, the framework itself is very complicated. In addition, it is not open-source, I don't know what's going on.