In the process of many of the projects I have done, I have always had a unresolved issue in troubled me, that is the development of persistence. The development of persistence layers is generally either with CMP or use JDBC DAO. CMP does not have to be said, it is a failed practice for me, and JDBC Dao has a lot of difficulties. I am very difficult to make the relationship of the relationship table to the relationship of the lasting object, which is mainly reflected. The relationship between the multi-table cannot be directly mapped to the map of the persistent object, which may be a table mapping multiple persistent objects, which may be multiple tables to map a persistent object, and some of the tables are mapped to one Persistent objects, but other fields are mapped to other persistent objects. And even if these problems are processed, you can't program a lasting object (PO) in the way, because there is a 1: n relationship's persistent object's query is actually 1 N times to the database of SQL, I have A failure layer design, the result is that a query of a lot of other lasting objects is 5N 1 time SQL, the speed is slow, and finally, the entire modification of the underlying design is completely abandoned, it is completely abandoned. Follow the table fields. But this is very uncomfortable, because the design is designed from demand, the system is designed, and the result is to the detailed design phase, and it is restricted by the persistent layer mapping problem. It is very bad to program the old road to program according to the process. I thought about this problem for a long time, and finally realized that this is actually a very classic problem: object and relationship mapping problem. In fact, since OOP programming, there is this problem, so some people have filed a relational database to redesign, switch to the object database, but in fact, the relational database is not eliminated, so it can only find a solution in the upper layer application layer. Program. At this time, I understand that what I need is actually an ORM product. The ORM I thought in was JDO, so I downloaded two JDO products, prepared to study hard, but after a period of time, I found that I was very disappointed with JDO, the reasons are as follows: 1, JDO does not have a good open source Free realization, good products are commercial products and have no sales and technical support in China. This caused JDO only to learn, it could not be used in the actual project, otherwise, when you sell the software to the customer, you have to tell him, you have to buy an abroad product product, and There is no technical support in China. If you have a long-lasting layer, we can't solve it. Please make an international long distance to solve the problem. Do you think customers can promise? 2, JDO is not a lightweight package, it tries to establish a complete persistent layer frame, but it is still very imperfect, causing JDO feeling more cumbersome, many ways to make people feel cumbersome and weird. This has increased the burden of programmer learning and programming, and the package will cause a serious problem to make an error message, it is very difficult to debug, you are difficult to accurately position the error, the smoother, the smoother, The easier if the problem is, the more easily solve, the heavier the package, the more complicated the problem, the more you can't find the reason, the CMP is a good example, the error, the error, the debugging is very difficult and trouble. 3, JDO standard is very imperfect, there is a major defect.
The most important problem is reflected in the PO. It does not exist from PM (equivalent to Hibernate's session). This is a very serious problem that will cause a lot of VO to make a lot of VO when making programming, and it is static. Pojo's Enhancer, can not run the Dynamic enhance, unable to perform incremental compilation and debugging, programming, and debugging, it is very cumbersome, each time you have a total of a tool to enhance for Pojo; there are some defects, such as JDOQL is not perfect, The expression of mapping relationship is not strong enough. 4, the split of JDO products. This problem is also more serious, due to the defects of JDO1.0 standards, and JDO2.0 standard is still out of date, and each JDO manufacturer is able to stand out in the competition, in addition to improving the operation and performance, Attracting customers, you must have your own product characteristics. So 1.0 standard defects just give the stage where they play, each manufacturer will have its own unique solution to solve the standard defect, but this has caused JDO products in fact split. What exempted this split is? I can make an example: you write good Pojo, using a JDO Enhancer to enhance gets the PO, running on another JDO product. This is very similar to the split of UNIX, the result is the incompatibility of binary code level, but can only be compatible with C source code levels. The current JDO has this trend, just like the difference in App Server, a developed EJB on WebLogic, transplanted to WebSphere, you must re-configure it. The ORM in my mind has the following characteristics: 1. Open source and free license, I can study the source code, rewrite the source code, and perform custom customization when needed. 2, lightweight package, avoid introducing too much complex problems, easy to debug, and also reduce the burden of programmers. 3, with scalability, Open, when it is not enough, you can expand your own code. 4. Developers are active, and the product has a stable development guarantee. After abandoning JDO, I used to eliminate Toplink, Cocobase, Castor, etc. according to the principles above, and finally selected Apache Ojb and Hibernate. OJB exclusion is easy to make, one because its document is too simple, too small; second, because the OJB plan has fully supported JDO, its API will have major changes, so at this stage study OJB is an error, wait for it The API is stable after it is not too late. Hibernate discovery is a very casual thing, just in the product of JDO, it comes with it, but when I started studying Hibernate, I found that I finally found the ORM I dreamed of. Hibernate is completely in line with the standards mentioned above, but also solves all of the shortcomings of JDO, and the improvement of the way. Hibernate's document is also very very distinctive, it is not only the function of Hibernate, it is actually a summary of the best practices for lasting layer design, examples inside the document, and the summary of the document is all Optimal design crystallization. I seriously read the feeling of Hibernate, not only to hold Hibernate, and the experience of the designed designed design has grown a large piece, and it has never been a lot of learning in the design of the lasting layer. This also felt that Gavin is definitely a big cattle.
