I've always had an open question that bothered me during many projects I've worked on, that is, the development of the persistence layer. Generally speaking, the development of persistence layer is either CMP or JDBC + DAO. Needless to say, CMP is a failed practice for me, and JDBC+DAO also has many difficulties. It is difficult for me to fully map the relationship table records to the relationship of persistent objects. This is mainly reflected in the fact that the relationship of multiple tables cannot be directly mapped to the mapping of persistent objects. It may be that a table maps multiple persistent objects, and it may be that multiple tables map a persistent object. More likely that some fields of the table map to a persistent object, but other fields map to other persistent objects. Moreover, even if these problems are handled, we cannot directly program persistent objects (POs) in the form of objects, because there is a 1:N relationship query for persistent objects is actually 1+n times for database SQL. I once failed persistent layer design, but the result is that a PO query related to many other persistent objects is 5n+1 times for SQL. It is extremely slow. In the end, I had to modify the underlying design entirely, and finally I completely abandoned the object design and operated completely according to the table fields.
However, it is very uncomfortable to do this because the system design is based on demand design and system design from top to bottom. As a result, it has reached the detailed design stage. It is limited by the persistence layer mapping problem and has to modify the design plan from bottom to top, and then return to the old path of programming according to the process, which is very bad.
I thought about this issue for a long time, and finally realized that it is actually a very classic problem: the mapping of objects and relationships. In fact, since OOP programming became popular, this problem has existed, so some people proposed to redesign the relational database and switch to the object database. However, in fact, the relational database was not eliminated, so they could only find solutions at the upper application layer. At this time I realized that what I needed was actually an ORM product.
The first ORM I thought of was JDO, so I downloaded two JDO products and prepared to study them carefully. However, after a while of research, I found that I was very disappointed with JDO for the following reasons:
1. JDO does not have a good open source and free implementation. Good products are commercial products and there is no sales or technical support in China. This causes JDO to be only used for learning and cannot be used in actual projects. Otherwise, when you sell the software to a customer, you have to tell him that you have to buy another foreign software product, and there is no technical support in China. If there is a persistent layer problem, we cannot solve it. Please make a long-distance international solution yourself to solve the problem. Do you think the customer can agree?
2. JDO is not a lightweight package. It tries to build a complete persistence layer framework, but it is still very imperfect, which makes JDO feel more bulky and many operation methods feel cumbersome and weird. This increases the burden on programmers to learn and program, and too much encapsulation will cause a serious problem. Once an error message occurs, it is very difficult to debug. It is difficult for you to accurately locate where the error occurs. The lighter the encapsulation, the easier it is to locate and solve the problem. The heavier the encapsulation, the more complicated the problem, and the less likely it is to find the cause. CMP is a good example. If an error occurs, it is very difficult and troublesome to debug.
3. The JDO standards are very imperfect and have major flaws. The most important problem is that PO cannot exist without PM (equivalent to Hibernate Session). This 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 cannot dynamically enhance during runtime, and cannot perform incremental compilation and debugging. It is very cumbersome to program and debug. Every time, you have to run a tool to enhance POJO; in addition, there are some defects, such as incomplete JDOQL, inadequate expression of mapping relationships, etc.
4. The division of JDO products. This problem is also quite serious. Due to the defects of the JDO1.0 standard, the JDO2.0 standard is still far away. In order to stand out in the competition, various JDO manufacturers must have their own product characteristics in addition to improving their ease of operation and performance. Then the defects of the 1.0 standard give them a stage to play. Each manufacturer will have its own unique solution to solve the defects of the standard, but this has caused the de facto division of JDO products. How serious is this division? I can give a brief example: if you wrote a POJO, you can use a JDO Enhancer to perform the PO you get after Enhancement, and it will not be able to run on another JDO product. This is very similar to the Unix split back then, and the result is binary code-level incompatibility, but only at the C source code level. JDO also has this trend now. Just like the difference between App Server, an EJB developed on Weblogic is ported to Websphere, and you must reconfigure it.
The ORM in my mind is best to have the following characteristics:
1. Open source and free license. I can study source code, rewrite source code, and customize functions when needed.
2. Lightweight packaging avoids the introduction of too many complex problems, is easy to debug, and also reduces the burden on programmers.
3. It is extensible and has an open API. When the functions themselves are not sufficient, you can expand by yourself.
4. Active developers and stable development guarantees for products.
After abandoning JDO, I followed the above principles and successively excluded TopLink, CocoBase, Castor, etc., and finally chose Apache OJB and Hibernate.
OJB is easy to eliminate, one is because its documentation is too simple and too little; the other is because the next version of OJB plans to fully support JDO, and its API will have major changes. Therefore, it is a mistake to learn OJB at this stage. It is not too late to learn after its API is stable.
Hibernate's discovery was a very accidental thing, but when someone mentioned JDO's products, it was mentioned at the same time. But when I started to study Hibernate, I found that I finally found the ORM I dreamed of.
In addition to fully complying with the standards I mentioned above, Hibernate also solves all the shortcomings of JDO, and the elegant method is amazing. Hibernate's documentation is also very distinctive. It is not just a simple introduction to the functions of Hibernate. It is actually a summary of experience in the best practices of persistent layer design. The examples in the document and the summary in the document are all the crystallization of the best design. The feeling I read Hibernate seriously is that not only have Hibernate mastered, but also have a lot of experience in designing persistent layers. I never thought that there was so much knowledge in designing persistent layers, and I also felt that Gavin was definitely a great man.
Of course, the reason why Hibernate is most reusable is that Hibernate is a software that I can completely control. Hibernate has very few source codes and is written very concisely. I always find it strange that such a small amount of source code can achieve so many functions, which is a miracle. Hibernate's source code tree is very clear and simple, and the source code is very easy to read. Once I encounter problems that are not mentioned in the document, or something mentioned in the document but I can't figure it out, I go to the source code to find them. All the problems are suddenly clear, and I have made it very clear about the operating principles and details of Hibernate. It seems that Hibernate is like the code I wrote myself. I know very clearly how to write a program to make Hibernate run the most efficient and save the most memory. If there is an error in the program, I know very clearly where the problem is and how to solve it. So using Hibernate makes me feel very at ease. I can control it, unlike those overly complex software, which has a very complex framework. In addition, it is not open source, so I don’t know what’s going on if something goes wrong.
However, it is very uncomfortable to do this because the system design is based on demand design and system design from top to bottom. As a result, it has reached the detailed design stage. It is limited by the persistence layer mapping problem and has to modify the design plan from bottom to top, and then return to the old path of programming according to the process, which is very bad.
I thought about this issue for a long time, and finally realized that it is actually a very classic problem: the mapping of objects and relationships. In fact, since OOP programming became popular, this problem has existed, so some people proposed to redesign the relational database and switch to the object database. However, in fact, the relational database was not eliminated, so they could only find solutions at the upper application layer. At this time I realized that what I needed was actually an ORM product.
The first ORM I thought of was JDO, so I downloaded two JDO products and prepared to study them carefully. However, after a while of research, I found that I was very disappointed with JDO for the following reasons:
1. JDO does not have a good open source and free implementation. Good products are commercial products and there is no sales or technical support in China. This causes JDO to be only used for learning and cannot be used in actual projects. Otherwise, when you sell the software to a customer, you have to tell him that you have to buy another foreign software product, and there is no technical support in China. If there is a persistent layer problem, we cannot solve it. Please make a long-distance international solution yourself to solve the problem. Do you think the customer can agree?
2. JDO is not a lightweight package. It tries to build a complete persistence layer framework, but it is still very imperfect, which makes JDO feel more bulky and many operation methods feel cumbersome and weird. This increases the burden on programmers to learn and program, and too much encapsulation will cause a serious problem. Once an error message occurs, it is very difficult to debug. It is difficult for you to accurately locate where the error occurs. The lighter the encapsulation, the easier it is to locate and solve the problem. The heavier the encapsulation, the more complicated the problem, and the less likely it is to find the cause. CMP is a good example. If an error occurs, it is very difficult and troublesome to debug.
3. The JDO standards are very imperfect and have major flaws. The most important problem is that PO cannot exist without PM (equivalent to Hibernate Session). This 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 cannot dynamically enhance during runtime, and cannot perform incremental compilation and debugging. It is very cumbersome to program and debug. Every time, you have to run a tool to enhance POJO; in addition, there are some defects, such as incomplete JDOQL, inadequate expression of mapping relationships, etc.
4. The division of JDO products. This problem is also quite serious. Due to the defects of the JDO1.0 standard, the JDO2.0 standard is still far away. In order to stand out in the competition, various JDO manufacturers must have their own product characteristics in addition to improving their ease of operation and performance. Then the defects of the 1.0 standard give them a stage to play. Each manufacturer will have its own unique solution to solve the defects of the standard, but this has caused the de facto division of JDO products. How serious is this division? I can give a brief example: if you wrote a POJO, you can use a JDO Enhancer to perform the PO you get after Enhancement, and it will not be able to run on another JDO product. This is very similar to the Unix split back then, and the result is binary code-level incompatibility, but only at the C source code level. JDO also has this trend now. Just like the difference between App Server, an EJB developed on Weblogic is ported to Websphere, and you must reconfigure it.
The ORM in my mind is best to have the following characteristics:
1. Open source and free license. I can study source code, rewrite source code, and customize functions when needed.
2. Lightweight packaging avoids the introduction of too many complex problems, is easy to debug, and also reduces the burden on programmers.
3. It is extensible and has an open API. When the functions themselves are not sufficient, you can expand by yourself.
4. Active developers and stable development guarantees for products.
After abandoning JDO, I followed the above principles and successively excluded TopLink, CocoBase, Castor, etc., and finally chose Apache OJB and Hibernate.
OJB is easy to eliminate, one is because its documentation is too simple and too little; the other is because the next version of OJB plans to fully support JDO, and its API will have major changes. Therefore, it is a mistake to learn OJB at this stage. It is not too late to learn after its API is stable.
Hibernate's discovery was a very accidental thing, but when someone mentioned JDO's products, it was mentioned at the same time. But when I started to study Hibernate, I found that I finally found the ORM I dreamed of.
In addition to fully complying with the standards I mentioned above, Hibernate also solves all the shortcomings of JDO, and the elegant method is amazing. Hibernate's documentation is also very distinctive. It is not just a simple introduction to the functions of Hibernate. It is actually a summary of experience in the best practices of persistent layer design. The examples in the document and the summary in the document are all the crystallization of the best design. The feeling I read Hibernate seriously is that not only have Hibernate mastered, but also have a lot of experience in designing persistent layers. I never thought that there was so much knowledge in designing persistent layers, and I also felt that Gavin was definitely a great man.
Of course, the reason why Hibernate is most reusable is that Hibernate is a software that I can completely control. Hibernate has very few source codes and is written very concisely. I always find it strange that such a small amount of source code can achieve so many functions, which is a miracle. Hibernate's source code tree is very clear and simple, and the source code is very easy to read. Once I encounter problems that are not mentioned in the document, or something mentioned in the document but I can't figure it out, I go to the source code to find them. All the problems are suddenly clear, and I have made it very clear about the operating principles and details of Hibernate. It seems that Hibernate is like the code I wrote myself. I know very clearly how to write a program to make Hibernate run the most efficient and save the most memory. If there is an error in the program, I know very clearly where the problem is and how to solve it. So using Hibernate makes me feel very at ease. I can control it, unlike those overly complex software, which has a very complex framework. In addition, it is not open source, so I don’t know what’s going on if something goes wrong.