Robbin: Why do I have to learn hibernate?

Author: Robbin

In the course of many projects I have done, I have always had an unresolved problem that bothers me, and that is the development of the persistence layer. The development of the persistence layer is generally either CMP or Jdbc+dao.  CMP Needless to say, it is a failure for me to practice, and Jdbc+dao also have a lot of difficulties, I am very difficult to make the relationship table records complete mapping to the relationship between the persistent object, this is mainly reflected in the relationship between multiple tables can not map directly to the map of persistent objects, It is possible that a table maps multiple persistent objects, possibly multiple tables mapping a persistent object, and more likely that some of the table's fields are mapped to a persistent object, but other fields are mapped to other persistent objects. And even if all these problems are dealt with, it is not possible to program the persistent object (PO) directly in the way of the object, because the query for the persistent object of the 1:n relationship is actually the SQL of the 1+n database, I once had a failed persistence layer design, The result is a number of other persistent objects of the PO query is 5n+1 times  sql, the speed is very slow, and finally have to modify the bottom of the design, the last is tantamount to completely abandoned the object design, completely according to the table field to operate.   But it's very hard to do, because the design of the system from the requirements of the design, system design Such a top-down, the results are detailed design phase, the persistence layer mapping problem restrictions, have to modify the design from the bottom up, and back to the process of programming in the old way up, very bad.   I've been thinking about it for a long time and finally realize it's a classic question: the mapping of objects and relationships. In fact, since OOP programming has been popular, this problem exists, so someone proposed the relational database redesign, instead of object database, but in fact, the relational database has not been eliminated, so it can only be in the upper tier of the application layer to find solutions. And then I realized what I needed was actually a  orm product.   The first ORM I thought of was jdo, so I downloaded two jdo products and I was ready to study hard, but after studying for a while, I found that I was very disappointed with JDO for the following reasons:  1,  jdo not a good open source for free implementation, Good products are commercial products, and there is no sales and technical support at home. This has caused JDO to learn only and not to use it in real projects, otherwise, you sell the software to customers, but also to tell him that you have to buy another foreign software products, and there is no technical support at home, a persistent layer of problems, we can not solve, please make your own international long-distance to solve the problem , do you think the customer can say yes?   2, JDO is not a lightweight package, it tries to build a complete persistence layer framework, but is still very imperfect, resulting in JDO  it feels cumbersome and many ways of doing things are tedious and bizarre. This adds to the burden of programmer learning and programming, and too much encapsulation can create a serious problem when an error message is present debugging is very difficult, you can not accurately locate the error exactly where the package of the lighter, the more easy to locate the problem, the more easy to solve, encapsulation of the heavier, the problem more complex, the more difficult to find reasons, CMP is a good example of a mistake, and debugging is very difficult and troublesome.   3, JDO standards are not perfect, there are major deficiencies. The main problem is reflected in the PO can not be separated from the PM (equivalent to  hibernate session) and exist, this is a very serious problem, will cause the programming time to do a lot of VO copy operation, very cumbersome; Another major flaw is the static   Pojo Enhancer, can not run the dynamic enhance, can not be incremental compilation and debugging, programming and debugging up very cumbersome, every time to run a tool on the Pojo  Enhance; there are also some defects, such as JDOQL imperfect, The expression of mapping relationship is not strong enough and so on.   4, the division of JDO products. This problem is also more serious, due to JDO1.0 standard defects, and the JDO2.0 standard is still in the foreseeable future, and each JDO manufacturers in order to be able to stand out in the competition, in addition to ease of operation and performance improvement, to attract customers, you must have their own product characteristics. The 1.0-standard flaw gives them the stage to play, and each vendor will have its own unique solution to the standard flaw, but this creates a de facto division of the jdo  product. To what extent is this division so severe? I can give you a simple example: The Pojo you've written, the  po you've been enhance with a jdo enhancer, can't run on another JDO product. This is very much like the Unix split, the result is binary code level incompatibility, and only in the C source code level compatible. Now JDO also has this trend, like the difference between App server, a weblogic in the development of a good EJB, porting to WebSphere, you must be reconfigured.   My idea of ORM is best to have the following characteristics:  1, open source and free license, I can study the source code when needed, rewrite the source code, make the function customization.   2, lightweight packaging to avoid the introduction of too many complex problems, debugging easy, but also reduce the burden on the programmer.   3, with scalability, API open, when its own function is not enough time, you can go through the code to expand.   4, the developer is active, the product has the stable development safeguard.  Abandoned JDO, I according to the above principles, has ruled out the Toplink,cocobase,castor, and finally selected APACHE OJB and hibernate.   OJB's exclusion is easy to make, because its documentation is too simple, too small, and because the next version of OJB plans to fully support JDO, its API will have significant changes, so at this stage learning OJB is a mistake, so it's not too late to learn when the API is stable. The discovery of   hibernate was a fortuitous thing to mention in the product of JDO, but when I began to study hibernate, I found that I had finally found the ORM I dreamed of.   hibernate  is perfectly consistent with the standards I mentioned above, and resolves all of JDO's flaws, and the elegance of the approach is admirable. Hibernate's documentation is also very, very distinctive, and it's not just a  hibernate feature introduction, it's actually an empirical summary of best practices in a persistence layer design, examples in the documentation, and a summary of all the best designs in the document. I seriously hibernate read down the feeling is that not only the hibernate mastered, but also the design of the durability of the experience of a large chunk, previously can never feel the design of the persistence layer there are so much knowledge, it also felt that Gavin is definitely a Daniel.   Of course the reason to choose Hibernate most reuse is that Hibernate is a software that I can totally manage. Hibernate source code is very few, and write very concise, I always feel quite strange, so few source code can realize so many functions, is a miracle.  hibernate Source code tree is very clear and simple, the source is very readable, I once encountered in the document did not mention the problem, or the document mentioned but I do not know where, I went to the source code to find, all the questions are suddenly enlightened, And let me hibernate operating principles and details of the special clear, as if the hibernate like their own code to write, very clear, how to write the program can make the hibernate run the most efficient, the most provincial memory, the program out of error, very clearly know what is the problem, How to solve. So I'm particularly relieved to use Hibernate,