Java开源项目Hibernate
程序员文章站
2023-12-12 13:50:46
一）hibernate意义 在一个真正的ooad中，我们的设计首先是做uml建摸，最终将一个系统涉及所有对象（这个东西不是东西那么简单）用类图来体现一个完整的设计，...
一）hibernate意义
在一个真正的ooad中，我们的设计首先是做uml建摸，最终将一个系统涉及所有对象（这个东西不是东西那么简单）用类图来体现一个完整的设计，我们最后可能得到这几种类：控制业务逻辑的类，保存业务数据的类module（bean类），辅助类或者更多（具体问题具体分析，但是将业务所需数据归结为一个类module更适合分层）。到数据库低层实现的时候，
为了获取数据或者存储数据，你不得不为此加上一个操作数据库的控制逻辑，到此，你完美的设计估计会为此付出巨大的努力，因为你看到的业务数据层是一个复杂的模块，即使从面向对象观点来看，我们uml类图中的，业务数据层只是一个数据模块。hibernate已经帮我们解决了业务数据层这个本来十分复杂的模块的底层实现，现在，我们只要在外层裹上我们的代表数据的类即可。
二）对象模型与关系数据库模型差异
在写出我初探hibernate的感受之前，我觉得写下这一节还是很有必要的。带着问题研究远远比带着好奇研究要意义深远得多。
问题领域：
关系型数据库是存储数据的最好选择，但是随着oo技术日益发展，在persisitent层上关系型数据库的设计体系与oo体系格格不入，可以想象，当满脑子充斥着ooad的你想到怎么隔离满天飞的sql语句时，那是多么痛苦的表情。无论你的业务层设计多么完美，在真正储存数据或者加载数据时，你面对的无非是一大堆封装好的数据，这些数据在jdbc中已经完全失去对象（这里的对象称之为业务对象或许更为确切）的意义，你整体的ooad到此为止。为什么会造成这种情况呢？原因是对象模型与关系数据库模型根本设计体系之间的差别。
对象模型与关系数据库模型各自理论出发点是不同的：对象模型的理论体系可以简单归结为这两点：
1） 以对象看待世界。
2） 对象间关系（继承，关联，聚合，组合）维系着整体构成。
而关系数据库模型唯一出发点是有效储存数据，key是数据库的关键技术，关系在这里只是各个数据表的key之间的关联，这种关联我觉得应该称之为数据的关联，其表达的意义远远没有对象之间的关联那么深广。
那么，我现在最关心的问题是hibernate是怎么利用关系数据库的数据表key关联来表达对象之间的关系呢？
在进入正式研究hbernate之前，我们可以思索一下问题的似乎简单与似乎十分复杂的矛盾。
我们设计的代表数据层的所有类必须完美的体现在数据表之中。可以这样总结：
class-àtable
class1—(关系)---class2------〉table1---(关系)-----table2
问题的解决似乎很简单，特别是对于javabean构架，更是简单（看起来简单而已！！！）。
想象一个简单的javabean类：
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;
}
}
我们完全可以这样进行name映射：
classname-àtablename
propertynameàcolumnname
一个类实例就是table的一行。这个问题很简单的得到解决。
再进一步,考虑如下简单的一对一类关联：
public class class1{
public class2 class2;
public class2 getclass2()…
public void setclass2(class2 class2)…
}
public class class2{
public class1 class1;
public class1 getclass1()...
...
}
这种关系很显然是双向的，可以从class1中得到class2，反过来，也可以从class2中得到class1，那么体现到数据表中呢？首先可以肯定class1àtable1,class2àtable2;很显然，table1和table2都要互相增加多一列来保存对方的key。
这些简单的关系在数据库表的关联中得到了很好的支持，但是稍微复杂一点的呢？
诸如以下一个类：
public class s {
arraylist datas;
public list getdatas()..
public void setdatas(list datas)..
….
}
这里如果简单用上面所分析的propertyname-àcolumnname显然不可以，这种集合作为bean属性我们该怎么在数据表中得到很好体现呢？如果这些集合只是简单的string 集合，它在数据库表里面是怎么表述的呢？如果这些集合是保存某些类实例的，似乎可以转换为数据库表的一对多的关系？
另外一方面，继承体系是怎么在数据块表里面得到体现的呢？继承的关系怎么用数据库的关联关系表达呢？继承所涉及的动态类识别怎么在数据库中得到体现呢？
再往深处想一想，对于一个操作：
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()..
..
}
在业务逻辑中，我们会这样写代码：
book book=new book();
.bookstore.addbooks(book);
上面两行代码便已经清楚地建立了child与parent之间的关系，相对来说，数据库中的数据也应该根据这几行代码建立产生数据并建立这种关联。此时内存中的数据怎么跟数据库中的数据一致呢？
在一个真正的ooad中，我们的设计首先是做uml建摸，最终将一个系统涉及所有对象（这个东西不是东西那么简单）用类图来体现一个完整的设计，我们最后可能得到这几种类：控制业务逻辑的类，保存业务数据的类module（bean类），辅助类或者更多（具体问题具体分析，但是将业务所需数据归结为一个类module更适合分层）。到数据库低层实现的时候，
为了获取数据或者存储数据，你不得不为此加上一个操作数据库的控制逻辑，到此，你完美的设计估计会为此付出巨大的努力，因为你看到的业务数据层是一个复杂的模块，即使从面向对象观点来看，我们uml类图中的，业务数据层只是一个数据模块。hibernate已经帮我们解决了业务数据层这个本来十分复杂的模块的底层实现，现在，我们只要在外层裹上我们的代表数据的类即可。
二）对象模型与关系数据库模型差异
在写出我初探hibernate的感受之前，我觉得写下这一节还是很有必要的。带着问题研究远远比带着好奇研究要意义深远得多。
问题领域：
关系型数据库是存储数据的最好选择，但是随着oo技术日益发展，在persisitent层上关系型数据库的设计体系与oo体系格格不入，可以想象，当满脑子充斥着ooad的你想到怎么隔离满天飞的sql语句时，那是多么痛苦的表情。无论你的业务层设计多么完美，在真正储存数据或者加载数据时，你面对的无非是一大堆封装好的数据，这些数据在jdbc中已经完全失去对象（这里的对象称之为业务对象或许更为确切）的意义，你整体的ooad到此为止。为什么会造成这种情况呢？原因是对象模型与关系数据库模型根本设计体系之间的差别。
对象模型与关系数据库模型各自理论出发点是不同的：对象模型的理论体系可以简单归结为这两点：
1） 以对象看待世界。
2） 对象间关系（继承，关联，聚合，组合）维系着整体构成。
而关系数据库模型唯一出发点是有效储存数据，key是数据库的关键技术，关系在这里只是各个数据表的key之间的关联，这种关联我觉得应该称之为数据的关联，其表达的意义远远没有对象之间的关联那么深广。
那么，我现在最关心的问题是hibernate是怎么利用关系数据库的数据表key关联来表达对象之间的关系呢？
在进入正式研究hbernate之前，我们可以思索一下问题的似乎简单与似乎十分复杂的矛盾。
我们设计的代表数据层的所有类必须完美的体现在数据表之中。可以这样总结：
class-àtable
class1—(关系)---class2------〉table1---(关系)-----table2
问题的解决似乎很简单，特别是对于javabean构架，更是简单（看起来简单而已！！！）。
想象一个简单的javabean类：
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;
}
}
我们完全可以这样进行name映射：
classname-àtablename
propertynameàcolumnname
一个类实例就是table的一行。这个问题很简单的得到解决。
再进一步,考虑如下简单的一对一类关联：
public class class1{
public class2 class2;
public class2 getclass2()…
public void setclass2(class2 class2)…
}
public class class2{
public class1 class1;
public class1 getclass1()...
...
}
这种关系很显然是双向的，可以从class1中得到class2，反过来，也可以从class2中得到class1，那么体现到数据表中呢？首先可以肯定class1àtable1,class2àtable2;很显然，table1和table2都要互相增加多一列来保存对方的key。
这些简单的关系在数据库表的关联中得到了很好的支持，但是稍微复杂一点的呢？
诸如以下一个类：
public class s {
arraylist datas;
public list getdatas()..
public void setdatas(list datas)..
….
}
这里如果简单用上面所分析的propertyname-àcolumnname显然不可以，这种集合作为bean属性我们该怎么在数据表中得到很好体现呢？如果这些集合只是简单的string 集合，它在数据库表里面是怎么表述的呢？如果这些集合是保存某些类实例的，似乎可以转换为数据库表的一对多的关系？
另外一方面，继承体系是怎么在数据块表里面得到体现的呢？继承的关系怎么用数据库的关联关系表达呢？继承所涉及的动态类识别怎么在数据库中得到体现呢？
再往深处想一想，对于一个操作：
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()..
..
}
在业务逻辑中，我们会这样写代码：
book book=new book();
.bookstore.addbooks(book);
上面两行代码便已经清楚地建立了child与parent之间的关系，相对来说，数据库中的数据也应该根据这几行代码建立产生数据并建立这种关联。此时内存中的数据怎么跟数据库中的数据一致呢？