DDR爱好者之家 Design By 杰米
一)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之间的关系,相对来说,数据库中的数据也应该根据这几行代码建立产生数据并建立这种关联。此时内存中的数据怎么跟数据库中的数据一致呢?
DDR爱好者之家 Design By 杰米
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
DDR爱好者之家 Design By 杰米
暂无评论...
P70系列延期,华为新旗舰将在下月发布
3月20日消息,近期博主@数码闲聊站 透露,原定三月份发布的华为新旗舰P70系列延期发布,预计4月份上市。
而博主@定焦数码 爆料,华为的P70系列在定位上已经超过了Mate60,成为了重要的旗舰系列之一。它肩负着重返影像领域顶尖的使命。那么这次P70会带来哪些令人惊艳的创新呢?
根据目前爆料的消息来看,华为P70系列将推出三个版本,其中P70和P70 Pro采用了三角形的摄像头模组设计,而P70 Art则采用了与上一代P60 Art相似的不规则形状设计。这样的外观是否好看见仁见智,但辨识度绝对拉满。
更新日志
2024年12月26日
2024年12月26日
- 小骆驼-《草原狼2(蓝光CD)》[原抓WAV+CUE]
- 群星《欢迎来到我身边 电影原声专辑》[320K/MP3][105.02MB]
- 群星《欢迎来到我身边 电影原声专辑》[FLAC/分轨][480.9MB]
- 雷婷《梦里蓝天HQⅡ》 2023头版限量编号低速原抓[WAV+CUE][463M]
- 群星《2024好听新歌42》AI调整音效【WAV分轨】
- 王思雨-《思念陪着鸿雁飞》WAV
- 王思雨《喜马拉雅HQ》头版限量编号[WAV+CUE]
- 李健《无时无刻》[WAV+CUE][590M]
- 陈奕迅《酝酿》[WAV分轨][502M]
- 卓依婷《化蝶》2CD[WAV+CUE][1.1G]
- 群星《吉他王(黑胶CD)》[WAV+CUE]
- 齐秦《穿乐(穿越)》[WAV+CUE]
- 发烧珍品《数位CD音响测试-动向效果(九)》【WAV+CUE】
- 邝美云《邝美云精装歌集》[DSF][1.6G]
- 吕方《爱一回伤一回》[WAV+CUE][454M]