1) Significance of Hibernate
In a real OOAD, the first thing we design is to build a UML model, and finally involve all objects in a system (this is not as simple as things) class diagrams are used to reflect a complete design. We may finally get the following types: class that controls business logic, class module that stores business data (Bean class ), auxiliary class or more (specific analysis of specific issues, but it is more suitable to classify the data required by the business into a class module ). At the lower-layer implementation of the database,
In order to obtain or store data, you have to add a control logic for operating the database. At this point, your perfect design is estimated to be a huge effort, because the business data layer you see is a complex module, even from the object-oriented perspective, in our UML class diagram, the business data layer is just a data module. Hibernate has helped us solve the underlying implementation of the originally complex module of the business data layer. Now, we only need to wrap our classes representing data in the outer layer.
2) differences between object models and relational database models
Before writing my feelings about hibernate, I think it is necessary to write this section. Research with questions is far more meaningful than research with curiosity.
Problem areas:
Relational databases are the best choice for data storage. However, with the increasing development of OO technology, the design system of relational databases on the persisitent layer is incompatible with the OO system. As you can imagine, how painful it is when you think of how to isolate SQL statements that are full of OOAD. No matter how perfect your business layer is, when you really store or load data, you are faced with a lot of encapsulated data, the data in JDBC has completely lost the meaning of the object (the object here is called the business object may be more accurate), so far your overall OOAD. Why does this happen? The reason is the difference between the basic design system of the object model and the relational database model.
The object model and the relational database model have different theoretical starting points: the theoretical system of the object model can be simply divided into the following two points:
1) view the world as an object.
2) relationships between objects (inheritance, association, aggregation, and combination) maintain the overall structure.
The only starting point of the relational database model is to effectively store data, and the key is the key technology of the database. The link here is only the association between the keys of each data table. I think this association should be called the Association of data, the meaning of the expression is far from that of the association between objects.
So what concerns me most now is how does hibernate use the data table key Association of relational databases to express the relationship between objects?
Before entering the formal study of hbernate, we can think about the seemingly simple and seemingly complex contradictions.
All classes designed to represent the data layer must be perfectly reflected in the data table. The following is a summary:
Class-à table
Class1-(relational) --- class2 ------> Table1 --- (relational) ----- Table2
The solution to the problem seems simple, especially for the JavaBean architecture (it looks simple !!!).
Imagine a simple JavaBean class:
Public class simplebean { Protected int ID; Protected string name; Public int GETID (){ Return ID; } Public void setid (int id ){ This. ID = ID; } Public String getname (){ Return name; } Public void setname (string name ){ This, name = Name; } } |
We can perform name ing like this:
| Classname-à tablename Propertyname à columnname |
A class instance is a row of a table. This problem is easily solved.
Further, consider the following simple one-to-one association:
Public class class1 { Public class2 class2; Public class2 getclass2 ()... Public void setclass2 (class2 class2 )... } Public class class2 { Public class1 class1; Public class1 getclass1 ()... ... } |
This relationship is obviously bidirectional. class2 can be obtained from class1, and class1 can also be obtained from class2, which is embodied in the data table? First, you can be sure that class1 à Table1, class2 à Table2; obviously, Table1 and Table2 must add one column to each other to save the key of the other party.
These simple relationships are well supported in the association of database tables, but a little more complicated?
For example, use the following class:
Public class S { Arraylist datas; Public list getdatas ().. Public void setdatas (list datas ).. .... } |
If we simply use the propertyname-à columnname analyzed above, it is obviously not acceptable. How can we make this set as a bean attribute well reflected in the data table? If these collections are just simple string collections, how do they be expressed in database tables? If these sets store some class instances, it seems that they can be converted into one-to-many relationships of database tables?
On the other hand, how is the inheritance system embodied in the data block table? How can inherited relationships be expressed using database associations? How does inheritance involve dynamic class recognition in databases?
Let's think further, for an operation:
Public class bookstore { Set books; Public set getboos ().. Public void setbooks (set boos )... Public void addbook (Book )... Public class book { Public bookstore; Public parent getbookstore ().. .. } |
In the business logic, we write the code as follows:
Book = New Book (); . Bookstore. addbooks (book ); |
The above two lines of code have clearly established the relationship between child and parent. Relatively speaking, the data in the database should also be created based on these lines of code to generate data and establish such associations. How is the data in the memory consistent with the data in the database?