ORM with Hibernate - 对象状态剖析

ORM其实有两个方面，一个是静态的mapping，也就是结构化的关系。一个对象与一张或者多张表怎么样对应。
还有一个方面就是动态关系。在应用中创建，查询，修改一些对象的时候，这些变化如何同步到到DB里面去，反过来，
DB的数据如果变了，怎么样反映到应用中的对象中来。换句话说，是内存中的对象是如何与DB里面的数据同步的。

关于如何mapping，使用hibernate的人都应该懂得，只是另一个动态的方面，初学者不重视，也不在意。不过会经常遇到一些问题，
抱怨hibernate复杂。我今天就和大家分享一下我的学习和理解。

首先理解一个概念，持久化上下文（persistence context），也就是一种缓存。它会记住app对object的更改，
择机同步到DB里面去。还有一个概念是持久化管理器（persistence manager），Session，通过它来操作对象，改变对象
与持久化上下文的关系。


持久化上下文（persistence context）
你可以把它看成是一级缓存，他缓存了所有的持久化对象。在Hibernate中每一个Session都有一个内部的持久化上下文。
你也许看不到它，你也不需要手动的开启它，实际上他默认而且必须被开启。但他帮你做了很多事情。
1. 变更检查以及后写入。既然是缓存就会发生被缓存的对象snapshot和DB不一致。因为不是所有的对象都变过，Hibernate就有
   一定的策略帮你找到变更过的对象，在适当的时候，通常是事务comment的时候更新到DB。见到数据库的压力。同样，在一个事务
   中，你也许对某一个对象做了很多次改变，Hibernate会在事务结束的时候合并变化一次更新，这就是后写入。这样可以减少对DB
   的lock时间。
2. 提供一级缓存，这样，当你要查询一个对象的时候，它会先在cache里面找，有就返回。这样就不用hit DB了。好处你懂得。
3. 保证java 对象标识。在同一个context里面，如果你对一个row查两次，context保证你只有一个对象产生，这样就保证只有一个
   对象与row对应。不会产生冲突，也节约内存。
4. Hibernate 可以帮你把这个context扩展到一个用户会话。尤其是在web应用时，很有用。


■ Hibernate can do automatic dirty checking and transactional write-behind.
■ Hibernate can use the persistence context as a first-level cache.
■ Hibernate can guarantee a scope of Java object identity.
■ Hibernate can extend the persistence context to span a whole conversation.

尽管如此，你也得善待持久化上下文。既然是缓存，就耗费内存，如果你无所顾忌的在一个事务中load大量不用的对象，就会内存溢出。

持久化上下文和数据库同步也就是Flushing的时机如下

■ When a Transaction on the Hibernate API is committed
■ Before a query is executed
■ When the application calls session.flush() explicitly

第二点特别注意，如果你不注意，查一句，改一句，查一句，再改一句，hibernate会不停的flush。performance就会有问题。

下面看看再Hibernate的概念中，对象的不同状态：Transient objects，Persistent objects， Removed objects 还有Detached objects。
有了持久化上下文（context）的概念以后，就好理解这四种状态了。Transient objects就是你刚刚创建（new），这时候context不知道有
她，当然也不会管它。一旦你save了它，Hibernate就把它放到context里面cache起来，也就是Persistent objects了。这时候对他的修改会在
事务flush的时候同步到DB里面去。如果你从DB里面load一个对象出来，它也是Persistent objects，但是如果你delete它，它就会被hibernate再flush的
时候从DB里面删除。在这之前是Removed objects，这种对象你最好不要再用它，也不要有对他的引用，因为它就是一个即将被删除的对象。对于一个Persistent object，
如果Session关闭了，自然也就没有人管了，他就是Detached objects。我感觉Detached objects和Transient objects也没有什么本质的区别。表面上看大概Transient objects
里面有db id，但Transient object里面没有。对于Removed objects，当Session关闭后也就变成Transient object，因为它和DB里面的数据没有关系。Detached objects虽然没有
人管，但是实际上它和DB里面的某个row关联。

关于Detached objects多说一点
因为人们经常会用这样的对象，比如你用DAO查出来以后返回到service或UI层。context关闭了，很正常也很必要。需要注意的是，如果你要对
这些对象执行euqals方法的时候，你要从写它的equals核和hashCode方法。尤其是你要用HashSet来存它的时候。因为如果你在一个新的context里面再load一个
和这个Detached object对应的同一条row的对象时，他们不是指向同一个对象引用，这样很危险，容易冲突。前面说了，只有再同一个context里面，hibernate才
帮你保证同一对象引用一个row。其实他是靠db id来判断的。Detached object可不一定都有db id，也许你后面修改了呢，db不知道。在实现equals方法的时候，也不要
用db id来比，最好用bussiness key，也就是业务上唯一的一组属性。

再说一下get和load方法的区别
1. load不会查询db，而是返回一个proxy。get会查询db。
2. 如果查不到，load会报ObjectNotFoundException。get会返回null。

load方法很有用，有很多时候你指向将他和另外一个对象关联，添加外键，这时候load就够了。这类情况很能改进performance。hibernate只在用到对象id以外属性的时候，
采取查db。