HibernateinAction学习笔记总汇.docx

Hibernate in Action学习笔记[2015年3月1日]目录Q1.面向对象应用程序中的持久化问题11.1范式不匹配11.2粒度问题11.3子类型问题11.4同一性问题11.5与关联相关的问题11.6数据访问方式的问题1Q2.如何解决这些持久化问题22.1为什么不使用分层架构，用DAO层解决。22.2为什么不使用Java序列化22.3为什么不使用面向对象数据库系统22.4为什么不用XML持久化22.5使用ORM2Q3.什么是ORM，包括哪些内容？3Q4.ORM质量等级3Q5.一般的ORM 问题3Q6.Hibernate 自由的开发过程4Q7.Hello Hibernate4面向对象应用程序中的持久化问题范式不匹配在电子商务系统中，用户与账单的关系为一对多关系。面向对象时设计为一个用户类与一个账单类。可以为用户类添加集合属性（集合中存储账单），也可以为账单类添加用户属性。但数据库表只能通过账单的外键来实现。假如用户信息中含有地址（国家、地区、省）等。面向对象时一般会封装为一个街道类，在用户类中持有街道类的属性解决。而数据库表中则不需要存在一个地址表。粒度问题这里粒度是指正在使用的类型的相对大小。面向对象允许我们无限的扩展类型，而SQL标准支持用户定义的数据类型却少的可怜。面向对象允许对象的嵌套组合，而数据库表只有两种粒度：表和列。子类型问题由于继承带来的问题。同一性问题Java中同一性通过 a == b 和 equals()检查，数据库通过外键检查。这样通常需要一个业务无关的代理键（UUID）来解决。同一性对系统如何处理高速缓存和事务密切相关。与关联相关的问题面向对象利用对象引用表示关联；但是在关系数据库中使用外键。对象引用由固有的方向性，而外键没有（可以通过表的联结和投影创建任意关联）数据访问方式的问题Java中可以使用aUser.getDetails().getAccountNumber()。而数据库必须考虑性能，而进行连结查询。也就是在你遍历对象网络之前要构建有效的连结查询！另一方面：懒加载机制总是期望在使用时在获得对象。但会产生N+1问题：如默认情况下，当Hibernate从数据库中加载Customer对象时，会同时加载所有关联的 Order对象。以Customer和Order类为例，假定ORDERS表的CUSTOMER_ID外键允许为null以下Session的find()方法用于到数据库中检索所有的Customer对象：?List customerLists=session.find(from Customer as c);?运行以上find()方法时，Hibernate将先查询CUSTOMERS表中所有的记录，然后根据每条记录的ID，到ORDERS表中查询有参照关系的记录，Hibernate将依次执行以下select语句：?select * from CUSTOMERS;?select * from ORDERS where CUSTOMER_ID=1;?select * from ORDERS where CUSTOMER_ID=2;?select * from ORDERS where CUSTOMER_ID=3;?select * from ORDERS where CUSTOMER_ID=4;?如何解决这些持久化问题为什么不使用分层架构，用DAO层解决。DAO是个好模式，甚至经常推荐与ORM一起使用，然而，给每个领域模型类编写持久化代码的工作量非常大，特别当支持多个SQL方言的时候。为什么不实现个简单映射框架呢？因为有Hibernate。（80000行代码，25000行测试代码）。为什么不使用Java序列化序列化之后的关联对象网络只能被当做一个整体访问：没有反序列化整个流，就不可能从流中获取任何数据。（在依赖序列化的网络传输中，要考虑此问题）为什么不使用面向对象数据库系统面向对象数据库系统没有流行起来。为什么不用XML持久化XML是序列化得一个变体，同时你可能遭受对象/层次结构不匹配的危险。使用ORM提高生产力提高可维护性性能损耗供应商独立性实现JPA标准什么是ORM，包括哪些内容？ORM就是利用描述对象和数据库之间映射的元数据，自动（且透明）的把Java应用程序中的对象持久化到关系数据库中的表。本质是：把数据从一种表示法（可逆）转换为另一种表示法进行工作。ORM解决方案包含下面的4个部分:在持久化类的对象上执行基本的CRUD操作的一个API ;用于指定引用类或者类属性的查询的一种语言或者API用于指定映射元数据的一种工具:用于实现ORM的一项技术，与事务对象交互，执行脏检查( dirty checking ) 、延迟关联抓以及其他优化功能。ORM质量等级纯关系——整个应闸程序(包括用户界面)都围