Hibernate in action学习笔记.docVIP

Hibernate in action学习笔记 理解O/R持久化 一，常见的设计难点： 用一个User和BillingDetails的例子来解释；User有多个Bill，User里面有User的相关信息，包括name, address等等，BillingDetails中用User的主键作为外键。 粒度问题 比如User的Adrress字段包括了city, street, zipcode等等信息，在Java中可以用一个Address类来持有这些信息，然而在数据库中情况就不一样了； 最直接的是现在的数据库大多都支持的UDT(user-defined column types)，可以将Address作为一个整体存入到数据库中，但是这样的类型在不同数据库中很难移植，所以在实践中很少用这样的方法； 通常的做法是在数据库中将Address的条目都作为单独的column，比如ADDRESS_CITY。 相比较而言，数据库只能表现出两层的粒度关系，显然不如Java的类型更加灵活。（书3.5） 子类型问题 （书3.6） Java中我们经常会用到继承，我们扩展一下上面的例子，我们为BillingDetails类扩展出一些子类：CreditCard, DirectDebit, Cheque等等。 我们需要建立几个不同的table来存储这些子类，然而数据库却并不支持它们之间的继承关系；一个标准的外键依赖严格地对应一个table，我们无法直接用一个外键对应多个表。 标识问题 （书3.4 5.0） 显然对于我们的User表，使用Username作为主键是一种很坏的设计，尤其当我们可能会改变username的时候，一般，我们会增加一个字段UserID来作为主键和外键使用。如何将这个字段对应到java中也是一个问题。 Java中通常会用==和equals()来判断两个对象是否相同，很多时候，会有多个不恒等的对象对应于数据库中同一条数据，如何正确的equals()就是一个问题。 如何关联的问题 （书3.0 6.0） 接下来我们关注一下映射和处理classes之间的关系到数据库中，所有的外键都是必需的么？ 在我们的例子中，Address, User, BillingDetails三个Class是关联的，然而在数据库中，不同的是BillingDetails独自一个表，而Address则不是。关联的映射和实体关联的管理在任何对象持久化的方案中都是中心的概念。 面向对象的语言使用对象引用和Collection来表现关联（association）。而在关系数据库中，关联是用foreign key来表示的。 对象的引用本身具有方向性，如果两个object有双向的关联，你就必须在两个object中都定义这种联系，比如在User中：private Set billingDetails; 而在BillingDetails中： private User user; Java中可能会有many-to-many的关联，而数据表之间只可能有one-to-many和one-to-one的关联； 如果你想在数据库中表现一个many-to-many的关联，则你需要引进一个新的联接表，这张表在对象模型中没有相应的表现，比如一个USER_BILLINGDETAILS表。 object graph navigation的问题 （书4.0 7.0） 在Java中，如果你要访问某个User的billing的信息，你会这样子做： someUser.getBillingDetails().getAccountNumber(); 这在面向对象中很自然，通常被叫做“walking the object graph”。然而在SQL数据库中，这样子就不是一种有效的方法； 提高数据访问效率的最简单重要的一点就是尽可能减少对数据库的request次数，也就是减少SQL查询的次数，（也可以使用存储过程和JDBC batch API）。 通常有效的对关联数据的查询是通过使用不同表之间的join来进行的，多少个表进行join取决于你访问对象的深度，比如： select * from USER u left outer join BILLING_DETAILS bd on ….. 总结： 解决上面的问题需要花费相当的时间和精力，根据经验，在一个Java应用中30%以上的代码是用来解决这些单调乏味的SQL/JDBC相关工作。 二，持久层和其他 在中大型的项目中，通常会按照职能组织classes，持久层就是其中之一。其他的关注层有表示，工作流，业务逻辑。还有所谓的“横切”关注，横切关注多半会被框架代码所实现。典型的横切关注有logging, authorization, transaction等等。 通常最好