I) Hibernate in a true OOAD, our design is first to do UML build, and finally put a system involved all objects (this thing is not as simple as simple) to reflect a complete design, we will finally get These kinds: Control business logic class, save business data class module (bean class), auxiliary class or more (specific analysis of specific issues, but the business required data is classified as a class MODULE more suitable layers). When the database is low-level implementation, in order to obtain data or store data, you have to add a control logic for the database, here, your perfect design estimate will pay great efforts to this, because you see the business The data layer is a complex module, even from the object-oriented point of view, our UML class diagram, the service data layer is just a data module. Hibernate has helped us solve the underlying implementation of this very complex module of the business data. Now, we can only wrap the class representing the data in the outer layer. II) The difference between the object model and the relational database model is written before I preliminarily feel the feelings of Hibernate, I think it is necessary to write this section. It is far more than a curiosity research. Problem: Relational database is the best choice for storing data, but as OO technology is growing, in the Persisitent Layer, the design system and OO system is inconsistent, you can imagine, when you are full of brains, what do you think of how you think about OOAD? What painful expression is that the SQL statement that is full of flying. Regardless of your business layer design, when you really save data or loading data, you face it is nothing more than a lot of packaged data, which has completely lost objects in JDBC (here the object is called business objects) Perhaps more exactly), your overall OOAD is here. Why do you cause this? The reason is the difference between the object model and the fundamental design system of the relational database model. Object model and relational database model Theoretical starting point is different: the theoretical system of object models can be simply concatenated to these two points: 1) look at the world with an object. 2) Inter-object relationship (inheritance, association, aggregation, combination) is maintained in whole. The only starting point of the relational database model is effective storage data. Key is a key technology of the database. The relationship is only the association between the key of the KEY of each data table. I think it should be called the association of the data. The meaning of expression is far away. The relationship between the absence of the object is so deep. So, what is the most concerned about how hibernate uses the relationship database of data table KEY associations to express the relationship between objects? Before entering the formal study hbernate, we can think that the problem seems to be simple and seemingly complex contradiction. All of our design representative data must be perfectly reflected in the data table. Can summary this: class-àtableclass1- (relationship) --- Class2 ------> table1 --- (relationship) ----- Table2 problem solves seem to be simple, especially for JavaBean architectures, Simple (it is 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 We can perform Name mappings in this way (this) {this, name = Name;
Classname-àtablenamepropertynameàcolumnname
A class instance is a line of Table. This problem is very simple to solve. Further, consider the following simple one-on-one association:
Public class class 1 {public class2 class; public class2 getclass2 () ... public void setclass2 (class2 class) ...} public class class2 {public class1 class1; public class1 getclass1 () ...}
This relationship is obviously two-way, can get Class2 from Class1, in turn, can also get Class1 from class 2, is it reflected in the data table? First, you can affirm class1àtable1, class2àtable2; it is clear that both Table1 and Table2 add more than one column to save each other's Key. These simple relationships have been well supported in the association of the database table, but is a little more complicated? Such a class:
Public class s {arraylist datas; public list getData () .. public void setData (list data) .. ....
Here, if the PropertyName-àcolumnname analyzed above is obviously not possible, this collection makes a bean property we have been very well reflected in the data table? If these collections are just a simple String collection, how is it expressed in the database table? If these collections are saved, it seems to be converted to a pair of relationships with a database table? On the other hand, how does the inheritance system are reflected in the data block table? How to express the relationship between the relationship of the inheritance? How to reflect the dynamic class recognition involved in the database? I want to think about it, for one action:
public class BookStore {Set books; Public Set getBoos () .. Public void setBooks (Set boos) ... Public void addBook (Book book) ... public class Book {public BookStore bookStore; public Parent getBookStore () .. ..}
In business logic, we will write code this:
Book book = new book () ;. Bookstore.Addbooks (book);
The above two lines of code have clearly established the relationship between Child and Parent. Relatively, the data in the database should also establish data and establish this association according to these lines of code. How does data in memory at this time are consistent with the data in the database?
