深入浅出Hibernate（国内第一本重量级Hibernate图书——原创精品）(2005年度北京地区版权贸易图书输出版权奖)
点击看大图基本信息
编辑推荐
国内第一本重量级围绕Hibernate3进行讲解的技术书籍，源于OpenDoc-Hibernate开发指南，内容扩编了6倍有余。 温馨提示：此书三位作者夏昕、曹晓钢、唐勇同意将此书的版税用于义务资助贵州惠水市吉安乡一个贫困山区的10个孩子未来两年的学杂费开销。
推荐阅读
内容简介回到顶部↑
本书由互联网上影响广泛的开放文档OpenDoc系列自由文献首份文档“Hibernate开发指南”发展而来。在编写过程中，进行了重新构思与组织，同时对内容的深度与广度进行了重点强化。本书从持久层入手，引出对象/关系数据库映射的由来，接下来聚焦于目前最完善、最强悍的ORM产品——Hibernate。从一个基础程序入手，讲述Hibernate的基本语法与配置，慢慢升高到缓存、延迟加载等高级特性。本书内容深入浅出，先讲述持久层设计与ORM，再由Hibernate概述、Hibernate基础Hibernate高级特性顺序展开，直至Hibernate实战，重点讲述了Hibernate的基础语法、基础配置、O/R映射、数据关联、数据检索、HQL实用技术、自定义持久化实现、Hibernate回调与拦截、Hibernate分页等实用技术，Hibernate实战部分则用一个真实论坛的创建演示了Hibernate的强大功能。本书有丰富的附录部，在附录中讲述了Hibernate常用的映射配置，Hibernate工具、XDoclet模板配置以及Hibernate的益友iBatis用法，还以卡片的形式列出了本书中所用的工具及软件，附录最后一部分是“快速启动代码”，供读者对比与参考，也给初学者提供了一个快带起步的基础。
本书适合于Hibernate的各个阶层的读者。
本书适合于Hibernate的各个阶层的读者。
作译者回到顶部↑
本书提供作译者介绍
夏昕
1979年8月27日出生。
完成了国内第一份比较全面的免费 Hibernate开发文档。
2003 Borland技术专家, “Dr Bobb’s Journal China”常任编委。译作《零缺陷编程》《UML业务建模》。OpenDoc项目发起人。
曹晓钢
1977年
Hibernate官方文档的翻译者。
从小热爱计算机屏幕上蹦出的一个个字符，感受到其>中的无穷乐趣，遂勤学不缀，尤喜对数据结构与算法的学习。RedSaga网站创立人，曾翻译过《深入Java虚拟机(第二版)》。愿为中国开放源代码事业的春天早日到>来而.. << 查看详细
1979年8月27日出生。
完成了国内第一份比较全面的免费 Hibernate开发文档。
2003 Borland技术专家, “Dr Bobb’s Journal China”常任编委。译作《零缺陷编程》《UML业务建模》。OpenDoc项目发起人。
曹晓钢
1977年
Hibernate官方文档的翻译者。
从小热爱计算机屏幕上蹦出的一个个字符，感受到其>中的无穷乐趣，遂勤学不缀，尤喜对数据结构与算法的学习。RedSaga网站创立人，曾翻译过《深入Java虚拟机(第二版)》。愿为中国开放源代码事业的春天早日到>来而.. << 查看详细
目录回到顶部↑
第1部分 持久层
第1章 面向应用的持久层设计 3
1.1 持久层概述 4
1.2 持久层设计 7
1.2.1 持久层设计与解耦合 7
1.2.2 持久层设计与资源管理模式 28
1.3 持久层设计与orm 42
1.3.1 orm概述 43
1.3.2 持久层实现类型 44
1.4 持久层框架概述 47
1.4.1 主流持久层框架纵览 48
第2部分 hibernate
第2章 hibernate概述 53
第3章 快速起步 57
3.1 准备工作 58
3.1.1 创建示例数据库 59
3.1.2 构建hibernate基础代码 59
3.1.3 由数据库产生基础代码 61
3.2 hibernate配置 68
3.3 日志配置 71
第1章 面向应用的持久层设计 3
1.1 持久层概述 4
1.2 持久层设计 7
1.2.1 持久层设计与解耦合 7
1.2.2 持久层设计与资源管理模式 28
1.3 持久层设计与orm 42
1.3.1 orm概述 43
1.3.2 持久层实现类型 44
1.4 持久层框架概述 47
1.4.1 主流持久层框架纵览 48
第2部分 hibernate
第2章 hibernate概述 53
第3章 快速起步 57
3.1 准备工作 58
3.1.1 创建示例数据库 59
3.1.2 构建hibernate基础代码 59
3.1.3 由数据库产生基础代码 61
3.2 hibernate配置 68
3.3 日志配置 71
译者序回到顶部↑
Hibernate… Hibernate?
两年前，笔者在为公司产品进行技术框架选型时，无意间在SourceForge项目列表中看到“Hibernate”这个陌生的名字。带着一丝迷惘与好奇，下载了这个小小的组件包，正是从这次信手点击开始，Hibernate已伴随着笔者征战了两个寒暑。如今，伴随着公司产品线的推广，Hibernate.作为产品的持久层支撑平台，已经在新加坡花旗银行、中国工商银行、中国银行的后台系统中默默地奉献了近一个春秋。
对于开源项目而言，可以相信，纵使极致华美的赞誉，也无法与一线工程师的信任与依赖相比肩。
2003年，Hibernate逐渐在国内流行，出于对Hibernate项目的信任与期待，笔者逐渐将自己在工作中的心得整理成文，于是产生了OpenDoc系列自由文献的首份文档——《Hibernate开发指南》，力图以此为Hibernate的推广尽一份绵薄之力。
本书也正是由《Hibernate开发指南》扩展而来的。《Hibernate开发指南》是自由发布的非正式文献，未免在结构和行文上比较随意散漫。本书编写过程中，根据OpenDoc读者的反馈，进行了重新构思和组织，同时对内容的广度和深度也进行了重点强化。较之《Hibernate开发指南》，本书内容扩充了6倍有余，涵盖至目前Hibernate最新版本3.0版的功能特性。
技术写作是一个漫长而艰苦的过程，值得庆幸的是，并非我一人独自承受这份通宵达旦的艰辛。好友晓钢和唐勇的加入使得这份工作平添了许多愉快和惬意。
晓钢是Hibernate官方文档中文版翻译的领导者，拥有国内独家Hibernate CVS账号，可算是Hibernate本地推广的先行者。
唐勇作为国内惟一Hibernate Eclipse插件（Tanghan Plugin）的作者，对Hibernate的开发与使用也积累了相当深厚的理论基础和实际经验。
有这两位挚友的加入，使得整个创作过程行云流水且充满乐趣。每每夜半，网络语音会议上，大家畅所欲言，从技术写作到娱乐八卦，无所不谈，那段时光充实而快乐，诚然是一段美好的回忆。
在本书即将与读者见面前夕，动手写这样一篇序言，心中充满期待与不安，读者的支持与反馈将是对我们最大的激励，希望本书能带给大家实质上的帮助。
夏 昕
2005年4月10日 夜
上 海
本书是我们三位作者通力合作的结果，夏昕不管在技术上还是现实生活中都体现出玉树临风的风范；唐勇是一位力战型选手，他把在工作中总结的宝贵经验传播到四面八方。作为一次开源项目的推广行动，一种特殊的自豪感也一直贯穿我们的写作过程。衷心希望读者能从本书中获得助益，进而加入到开放源代码的大军中来。
曹晓钢
2005年4月10日
本书源于夏昕关于Hibernate的OpenDoc（开源文档），这个文档在Java社区中流传很广，基本成为了学习Hibernate的基础教程。第一次看到这个文档，比较诧异，国内的技术人员还可以把技术入门文档写得这样深入浅出，不论文笔的流畅，还是内容的深度都很够“味道”。于是开始和夏昕联系，希望能以这个文档为基础写一本以Hibernate为主题的专题技术书籍。
Hibernate作为Java ORM的优秀开源实现，已经成为Java ORM的一种标准，为饱受JDBC折磨的开发者带来了“福音”。本书也希望能为那些想要应用和深入了解Hibernate的开发人员带来“福音”。
唐 勇
2005年4月10日
两年前，笔者在为公司产品进行技术框架选型时，无意间在SourceForge项目列表中看到“Hibernate”这个陌生的名字。带着一丝迷惘与好奇，下载了这个小小的组件包，正是从这次信手点击开始，Hibernate已伴随着笔者征战了两个寒暑。如今，伴随着公司产品线的推广，Hibernate.作为产品的持久层支撑平台，已经在新加坡花旗银行、中国工商银行、中国银行的后台系统中默默地奉献了近一个春秋。
对于开源项目而言，可以相信，纵使极致华美的赞誉，也无法与一线工程师的信任与依赖相比肩。
2003年，Hibernate逐渐在国内流行，出于对Hibernate项目的信任与期待，笔者逐渐将自己在工作中的心得整理成文，于是产生了OpenDoc系列自由文献的首份文档——《Hibernate开发指南》，力图以此为Hibernate的推广尽一份绵薄之力。
本书也正是由《Hibernate开发指南》扩展而来的。《Hibernate开发指南》是自由发布的非正式文献，未免在结构和行文上比较随意散漫。本书编写过程中，根据OpenDoc读者的反馈，进行了重新构思和组织，同时对内容的广度和深度也进行了重点强化。较之《Hibernate开发指南》，本书内容扩充了6倍有余，涵盖至目前Hibernate最新版本3.0版的功能特性。
技术写作是一个漫长而艰苦的过程，值得庆幸的是，并非我一人独自承受这份通宵达旦的艰辛。好友晓钢和唐勇的加入使得这份工作平添了许多愉快和惬意。
晓钢是Hibernate官方文档中文版翻译的领导者，拥有国内独家Hibernate CVS账号，可算是Hibernate本地推广的先行者。
唐勇作为国内惟一Hibernate Eclipse插件（Tanghan Plugin）的作者，对Hibernate的开发与使用也积累了相当深厚的理论基础和实际经验。
有这两位挚友的加入，使得整个创作过程行云流水且充满乐趣。每每夜半，网络语音会议上，大家畅所欲言，从技术写作到娱乐八卦，无所不谈，那段时光充实而快乐，诚然是一段美好的回忆。
在本书即将与读者见面前夕，动手写这样一篇序言，心中充满期待与不安，读者的支持与反馈将是对我们最大的激励，希望本书能带给大家实质上的帮助。
夏 昕
2005年4月10日 夜
上 海
本书是我们三位作者通力合作的结果，夏昕不管在技术上还是现实生活中都体现出玉树临风的风范；唐勇是一位力战型选手，他把在工作中总结的宝贵经验传播到四面八方。作为一次开源项目的推广行动，一种特殊的自豪感也一直贯穿我们的写作过程。衷心希望读者能从本书中获得助益，进而加入到开放源代码的大军中来。
曹晓钢
2005年4月10日
本书源于夏昕关于Hibernate的OpenDoc（开源文档），这个文档在Java社区中流传很广，基本成为了学习Hibernate的基础教程。第一次看到这个文档，比较诧异，国内的技术人员还可以把技术入门文档写得这样深入浅出，不论文笔的流畅，还是内容的深度都很够“味道”。于是开始和夏昕联系，希望能以这个文档为基础写一本以Hibernate为主题的专题技术书籍。
Hibernate作为Java ORM的优秀开源实现，已经成为Java ORM的一种标准，为饱受JDBC折磨的开发者带来了“福音”。本书也希望能为那些想要应用和深入了解Hibernate的开发人员带来“福音”。
唐 勇
2005年4月10日
前言回到顶部↑
计算机是人类又一伟大的发明。它的“记忆力”比人类更好，在完成精确任务方面比人类更稳定，可以惊人的速度毫不疲倦地完成大量工作，把人类从繁重的记忆与计算工作中解脱出来，其意义甚至超过了蒸汽机的发明。
软件凝聚了人类的无数聪明才智，就如同提线木偶身上纷繁复杂的提线一样，有条不紊地控制硬件运作。若是揭开软件表面的盖子一窥究竟，则犹如俯瞰巨大城市中的交通道路，数据如汽车般在“电子公路”上穿梭，运作良好的公路上井井有条，每一个数据都是鲜活的个体，它们有自己的生命周期，会不断繁衍消亡。
计算机应用系统犹如繁华都市，操作系统是城市的基础设施，数据库则是小区与道路的管理部门。拜数据库管理系统所赐，我们不再需要如同操纵提线木偶一般小心翼翼，只需要把数据扔到数据库接口中，在需要的时候，总是能够再次取出。有了数据库系统，我们的工作就从照顾单个数据，上升到分析城市人口容量，规划道路，以防止人口膨胀与交通堵塞的高度上来。数据库解放了我们跟踪数据的生产力。
作为程序员，每当我想到这些妙不可言之处，总是禁不住微笑起来。为了达到这样一个模拟城市的游戏般的目标，我们努力操纵着数据库。不幸的是，数据库的操纵本身，却并非那么好玩。
关系数据库的操作基于行集。因此，对于关系数据库接口的操纵，长期以来也都是基于行集的，ODBC, BDE (Borland Database Engine), ADO, ADO.NET,JDBC的各个版本，虽然增加了很多特性，但从功能上来却看毫无二致，应用程序承担着从行集中获取数据来展示的繁重工作。假若客户输入了查询条件，把查询条件翻译为数据库查询语言的工作，也是枯燥无味的。这些不断推出的数据存取方法，给开发人员带来的是有限的特性扩展，却让程序员如同推石头上山的西西弗斯一样，不断重复着学习的过程，也不禁开始嘀咕：为何那些大公司每隔几年就要重新“发明”一次数据库存取技术？
量变总会引起质变。
在另一条道路上，面向对象技术悄悄掩杀过来。那条道路是软件开发本身的科学，关注如何有效合理地组织代码，减少程序员的编码痛苦，用符合事物本原与适应人类自身思维方式的方法来组织程序。虽然面向对象技术发展的时间不算短，但高级面向对象技术的迅速普及,确实是发生在“设计模式”这一里程碑的总结出现之后。以往对面向对象技术的威力表示怀疑的人们,用学习了设计模式的眼光，再次审视自己的程序代码时，仿佛具有了哲人的眼睛，对程序设计的思想洞彻心扉。
风暴之后，大家已经学会从更高的层次来进行程序开发，在这个时候，JDBC这样面向行集的数据存取技术显已得是那样地呆板迟缓，从未这样碍眼过。人们意识到我们所缺乏的，是用符合事物本原的方式来访问数据。数据是灵活的，富有生命的，而如前所述数据库是小区管理部门与道路建设部门，是安置数据对象个体的居所。当数据活跃起来的时候，就让它阳光下充分表现自己的活力，动作舒展；当数据沉睡的时候，则为它遮风挡雨。
这是一个多么美妙而和谐的境界啊！当面向对象与数据管理结合起来时，人们知道，一场新的革命来临了，这就是Object /Relation Mapping ——对象/关系数据库映射。
在本书的第1章，我们就会来讲述对象/关系数据库映射的由来，持久层设计对应用程序开发的作用与地位。
后续的章节，聚焦于目前最完善和强悍的ORM产品——Hibernate。从一个基础的简单程序入手，我们讲述Hibernate的基本语法与配置，慢慢升高到缓存、延迟加载等高级特性，正是它们把JDBC与Hibernate的距离拉得更远了。
随后，我们会结合一个实例，讲述在实际项目开发中，如何使用Hibernate。这已经超越了Hibernate的语法，其中涉及的话题很广泛，从项目的组织，测试优先的原则，到Hibernate的优缺点，用实际的事例展示Hibernate的拦截器、父子映射等实现，让我们再次接受暴风雨般的洗礼吧！
最后，我们还提供了丰富的附录内容，其中包括对Hibernate的有益补充：iBatis的介绍，iBatis是一个独立的项目，可以视作是半自动化的城市管理者，让你可以自己插手来修建道路，或许你会感觉到别样的乐趣。
软件凝聚了人类的无数聪明才智，就如同提线木偶身上纷繁复杂的提线一样，有条不紊地控制硬件运作。若是揭开软件表面的盖子一窥究竟，则犹如俯瞰巨大城市中的交通道路，数据如汽车般在“电子公路”上穿梭，运作良好的公路上井井有条，每一个数据都是鲜活的个体，它们有自己的生命周期，会不断繁衍消亡。
计算机应用系统犹如繁华都市，操作系统是城市的基础设施，数据库则是小区与道路的管理部门。拜数据库管理系统所赐，我们不再需要如同操纵提线木偶一般小心翼翼，只需要把数据扔到数据库接口中，在需要的时候，总是能够再次取出。有了数据库系统，我们的工作就从照顾单个数据，上升到分析城市人口容量，规划道路，以防止人口膨胀与交通堵塞的高度上来。数据库解放了我们跟踪数据的生产力。
作为程序员，每当我想到这些妙不可言之处，总是禁不住微笑起来。为了达到这样一个模拟城市的游戏般的目标，我们努力操纵着数据库。不幸的是，数据库的操纵本身，却并非那么好玩。
关系数据库的操作基于行集。因此，对于关系数据库接口的操纵，长期以来也都是基于行集的，ODBC, BDE (Borland Database Engine), ADO, ADO.NET,JDBC的各个版本，虽然增加了很多特性，但从功能上来却看毫无二致，应用程序承担着从行集中获取数据来展示的繁重工作。假若客户输入了查询条件，把查询条件翻译为数据库查询语言的工作，也是枯燥无味的。这些不断推出的数据存取方法，给开发人员带来的是有限的特性扩展，却让程序员如同推石头上山的西西弗斯一样，不断重复着学习的过程，也不禁开始嘀咕：为何那些大公司每隔几年就要重新“发明”一次数据库存取技术？
量变总会引起质变。
在另一条道路上，面向对象技术悄悄掩杀过来。那条道路是软件开发本身的科学，关注如何有效合理地组织代码，减少程序员的编码痛苦，用符合事物本原与适应人类自身思维方式的方法来组织程序。虽然面向对象技术发展的时间不算短，但高级面向对象技术的迅速普及,确实是发生在“设计模式”这一里程碑的总结出现之后。以往对面向对象技术的威力表示怀疑的人们,用学习了设计模式的眼光，再次审视自己的程序代码时，仿佛具有了哲人的眼睛，对程序设计的思想洞彻心扉。
风暴之后，大家已经学会从更高的层次来进行程序开发，在这个时候，JDBC这样面向行集的数据存取技术显已得是那样地呆板迟缓，从未这样碍眼过。人们意识到我们所缺乏的，是用符合事物本原的方式来访问数据。数据是灵活的，富有生命的，而如前所述数据库是小区管理部门与道路建设部门，是安置数据对象个体的居所。当数据活跃起来的时候，就让它阳光下充分表现自己的活力，动作舒展；当数据沉睡的时候，则为它遮风挡雨。
这是一个多么美妙而和谐的境界啊！当面向对象与数据管理结合起来时，人们知道，一场新的革命来临了，这就是Object /Relation Mapping ——对象/关系数据库映射。
在本书的第1章，我们就会来讲述对象/关系数据库映射的由来，持久层设计对应用程序开发的作用与地位。
后续的章节，聚焦于目前最完善和强悍的ORM产品——Hibernate。从一个基础的简单程序入手，我们讲述Hibernate的基本语法与配置，慢慢升高到缓存、延迟加载等高级特性，正是它们把JDBC与Hibernate的距离拉得更远了。
随后，我们会结合一个实例，讲述在实际项目开发中，如何使用Hibernate。这已经超越了Hibernate的语法，其中涉及的话题很广泛，从项目的组织，测试优先的原则，到Hibernate的优缺点，用实际的事例展示Hibernate的拦截器、父子映射等实现，让我们再次接受暴风雨般的洗礼吧！
最后，我们还提供了丰富的附录内容，其中包括对Hibernate的有益补充：iBatis的介绍，iBatis是一个独立的项目，可以视作是半自动化的城市管理者，让你可以自己插手来修建道路，或许你会感觉到别样的乐趣。
评论交流
共有178人开贴评论 388人参与评论 164人参与打分 查看
评价等级：
发表于：2005-6-8 17:44:00
昨天看到听棠.NET对于学习NHibernate 提出了非常宝贵的意见，希望每次的研究或者玩一个工具都不要放弃，这点我绝对赞成（我们很多人都是一种3分钟的热度，老外就比较钻研一点，任何一个东西学精通了都很牛），也许你说中了很多点，但是也有些你没有说中，我经历了一些开发，虽然还不是很丰富，关于架构也略知一二。现在所在的公司，也有一些OR Mapping 的工具、代码，我自己没有达到他的水平，当然也写不出这样的代码。不过，至于我为什么要学习NHibernate, 你觉得 Nhibernate不好，但是 Hibernate 都已经有3.0了，为什么能够发展下去？为什么微软也在搞自己的OR Mapping 工具，呵，盲目崇拜、突出自己的水平，有必要吗？
相信熟悉Java的同志们都知道JavaEye这个网站，我想很多学习.Net的人也知道这个。她的创始人，Robbin，曾经写过为什么要学习Hibernate，以及如何学习Hibernate，最近刚刚出版的《 深入浅出Hibernate 》虽然他不是作者，但是我想他一定在这个过程中贡献过自己的力量（他们几个都很熟悉）。可以参考一下他的文章，虽然是2年前的了！听CSDN的编辑GiGix吹过一次牛，虽然他说的不一定正确，他提到了很多技术，很多很大的名词，最终总结了一句“古已有之”！
至于我，我自从学习开发软件以来，一直在考虑我们的OOA和OOD都是怎么做的，到底这些东西都是为了做个漂亮、专业的报告而搞出一点花样吗，还是为了真正解决项目中的问题。任何项目一开始，正规的做法都是做需求，做用例，也开始了画类图、对象图、序列图、设计界面、设计数据库，这样就结束了设计！但是真正开始了编码的时候，除了界面、数据库，其它几乎全部都抛弃了！为什么抛弃了，因为发现我们开始编码以后，我们就回到了Table模式，DataSet模式进行思考问题，这个表存放什么字段，两个表之间如何关联，就是Justin Gehtland所谓的tabular programming；而不是在考虑两个业务对象之间如何交互，如何发送消息了。为什么在OOA和OOD之间出现了这么大鸿沟呢？我们设计的类图和数据库的关系图、以及后续的Coding之间是否可以很好的过渡呢？OR Mapping，正如他的名字一样，Object Relationship Mapping，这里的O就是我们平时所说的面向对象，这里的R就是我们说的关系数据库，既然NHibernate生来就是为了解决这问题的，为什么不学习一下？了解一下他是怎么运作的。Martin Fowler先生在《 企业应用架构模式 》中极力推崇使用Domain Model进行领域模型的设计和开发，然后平滑的过渡、映射到数据库，我想NHibnernate也许能帮这个忙！
至于你说的SQL或者HQL的迷阵也好，还是性能问题也好，我觉得这个东西是其次的，都可以经过一段时间的熟练以后过渡过来，真正的软件设计的目标和目的肯定不是这个，而是如何实现项目的最终目标，满足客户的需求，保证开发人员对于需求的把握更佳！而不是每次来了Change Request以后，就开始了修改庞大的修改SQL语句的工程，也许有些片面，如果项目要Close了，势必要进行更新所有的类图，序列图和其他大量的文档，而此时，类图、序列图和其他文档反而成了一种累赘，那么为什么我们要他呢？
所以，总结一句，我是希望通过学习HNhibernate掌握持久层设计应该把握的原则和技巧，深刻地理解对象持久层设计理念！试图寻找一个更好的软件开发思路!!
其他Hibernate好书包括：
《 精通Hibernate :Java对象持久化技术详解 》(孙卫琴)
《 精通Hibernate 》(刘洋)
相信熟悉Java的同志们都知道JavaEye这个网站，我想很多学习.Net的人也知道这个。她的创始人，Robbin，曾经写过为什么要学习Hibernate，以及如何学习Hibernate，最近刚刚出版的《 深入浅出Hibernate 》虽然他不是作者，但是我想他一定在这个过程中贡献过自己的力量（他们几个都很熟悉）。可以参考一下他的文章，虽然是2年前的了！听CSDN的编辑GiGix吹过一次牛，虽然他说的不一定正确，他提到了很多技术，很多很大的名词，最终总结了一句“古已有之”！
至于我，我自从学习开发软件以来，一直在考虑我们的OOA和OOD都是怎么做的，到底这些东西都是为了做个漂亮、专业的报告而搞出一点花样吗，还是为了真正解决项目中的问题。任何项目一开始，正规的做法都是做需求，做用例，也开始了画类图、对象图、序列图、设计界面、设计数据库，这样就结束了设计！但是真正开始了编码的时候，除了界面、数据库，其它几乎全部都抛弃了！为什么抛弃了，因为发现我们开始编码以后，我们就回到了Table模式，DataSet模式进行思考问题，这个表存放什么字段，两个表之间如何关联，就是Justin Gehtland所谓的tabular programming；而不是在考虑两个业务对象之间如何交互，如何发送消息了。为什么在OOA和OOD之间出现了这么大鸿沟呢？我们设计的类图和数据库的关系图、以及后续的Coding之间是否可以很好的过渡呢？OR Mapping，正如他的名字一样，Object Relationship Mapping，这里的O就是我们平时所说的面向对象，这里的R就是我们说的关系数据库，既然NHibernate生来就是为了解决这问题的，为什么不学习一下？了解一下他是怎么运作的。Martin Fowler先生在《 企业应用架构模式 》中极力推崇使用Domain Model进行领域模型的设计和开发，然后平滑的过渡、映射到数据库，我想NHibnernate也许能帮这个忙！
至于你说的SQL或者HQL的迷阵也好，还是性能问题也好，我觉得这个东西是其次的，都可以经过一段时间的熟练以后过渡过来，真正的软件设计的目标和目的肯定不是这个，而是如何实现项目的最终目标，满足客户的需求，保证开发人员对于需求的把握更佳！而不是每次来了Change Request以后，就开始了修改庞大的修改SQL语句的工程，也许有些片面，如果项目要Close了，势必要进行更新所有的类图，序列图和其他大量的文档，而此时，类图、序列图和其他文档反而成了一种累赘，那么为什么我们要他呢？
所以，总结一句，我是希望通过学习HNhibernate掌握持久层设计应该把握的原则和技巧，深刻地理解对象持久层设计理念！试图寻找一个更好的软件开发思路!!
其他Hibernate好书包括：
《 精通Hibernate :Java对象持久化技术详解 》(孙卫琴)
《 精通Hibernate 》(刘洋)
)
加载中...| 我要写评论 |
| 查看所有评论交流(共178条) |
