The reason why I study hibernate

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 is needless to say, it is a failure of practice for me, and Jdbc+dao also have a lot of difficulties, it is difficult for me to put the relationship table records complete mapping to the relationship between the persistent object, which is mainly reflected in the multiple table relationship can not directly map 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 time 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 that, 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 thought about it for a long time and finally realized it was 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 an ORM product.

The first thing I thought of as Orm was JDO, so I downloaded two JDO products and was ready to study hard, but after studying for a while, I found I was very disappointed with JDO for the following reasons:

1, JDO does not have a good open source for free to achieve, good products are commercial products, and there is no sales and technical support in the country. 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 is trying to build a complete persistence layer framework, but still very imperfect, resulting in jdo feel more cumbersome, many ways of operation is cumbersome 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, cumbersome extremely; Another major flaw is the static pojo of enhancer, Can not run the dynamic enhance, can not be incremental compilation and debugging, programming and debugging up very cumbersome, each hand to run a tool for the pojo enhance; In addition, there are some defects, such as JDOQL imperfect, mapping the expression of the relationship is not strong 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. Then the 1.0-standard flaw gives them the stage to play, and each vendor has its own unique solution to the standard flaw, yet 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, with a jdo enhancer, enhance a PO that you get later, and you 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 in app server, a weblogic on the development of EJB, porting to WebSphere, you must be reconfigured.

My idea of ORM has the following characteristics:

1, open source and free license, I can study the source code when needed, rewrite the source code, carry on the customization of the function.

2, lightweight packaging, to avoid the introduction of too many complex problems, debugging easy, but also reduce the burden of programmers.

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.

After the abandonment of JDO, I according to the above principles, has ruled out toplink,cocobase,castor, and so on, and finally chose the 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.

Hibernate's discovery was a fluke, just a mention of the JDO product, but when I started studying 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 with hibernate I am particularly relieved, I can control it, and not like those too complex software, the framework itself is very complex, coupled with no open source, out of the problem also do not know how.