【IT168技术文档】 
    再谈谈saveOrUpdate的用场：
saveOrUpdate和update的区别就在于在跨Session的PO状态管理中，Hibernate对PO采取何种策略。 

    例如当你写一个DAOImpl的时候，让cat对象增加一个mate，如下定义： 

    代码

public void addMate(Cat cat, Mate mate) ...{
    Session session = ...;
    Transacton tx = ...;
    session.update(cat);
    cat.addMate(mate);
    tx.commit();
    session.close();
};  

    显然你是需要把Hibernate的操作封装在DAO里面的，让业务层的程序员和Web层的程序员不需要了解Hibernate，直接对DAO进行调用。 

    此时问题就来了：上面的代码运行正确有一个必要的前提，那就是方法调用参数cat对象必须是一个已经被持久化过的PO，也就是来说，它应该首先从数据库查询出来，然后才能这样用。但是业务层的程序员显然不知道这种内部的玄妙，如果他的业务是现在增加一个cat，然后再增加它的mate，他显然会这样调用，new一个cat对象出来，然后就addMate：

Cat cat = new Cat();
cat.setXXX();
daoimpl.addMate(cat,mate);  

    但是请注意看，这个cat对象只是一个VO，它没有被持久化过，它还不是PO，它没有资格调用addMate方法，因此调用addMate方法不会真正往数据库里面发送update的sql，这个cat对象必须先被save到数据库，在真正成为一个PO之后，才具备addMate的资格。 

    你必须这样来操作： 

    代码

Cat cat = new Cat();
cat.setXXX();
daoimpl.addCat(cat);
daoimpl.addMate(cat, mate);  

    先持久化cat，然后才能对cat进行其他的持久化操作。因此要求业务层的程序员必须清楚cat对象处于何种状态，到底是第一种，还是第三种。如果是第一种，就要先save，再addMate；如果是第三种，就直接addMate。 

    但是最致命的是，如果整个软件分层很多，业务层的程序员他拿到这个cat对象也可能是上层Web应用层传递过来的cat，他自己也不知道这个cat究竟是VO，没有被持久化过，还是已经被持久化过，那么他根本就没有办法写程序了。 

    所以这样的DAOImpl显然是有问题的，它会对业务层的程序员造成很多编程上的陷阱，业务层的程序员必须深刻的了解他调用的每个DAO对PO对象进行了何种状态管理，必须深刻的了解他的PO对象在任何时候处于什么确切的状态，才能保证编程的正确性，显然这是做不到的，但是有了saveOrUpdate，这些问题就迎刃而解了。 

    现在你需要修改addMate方法： 

    代码

public void addMate(Cat cat, Mate mate) ...{
    Session session = ...;
    Transacton tx = ...;
    session.saveOrUpdate(cat);
    cat.addMate(mate);
    tx.commit();
    session.close();
};  

    如上，如果业务层的程序员传进来的是一个已经持久化过的PO对象，那么Hibernate会更新cat对象(假设业务层的程序员在Session外面修改过cat的属性)，如果传进来的是一个新new出来的对象，那么向数据库save这个PO对象。 

    BTW: Hibernate此时究竟采取更新cat对象，还是save cat对象，取决于unsave-value的设定。 

    这样，业务层的程序员就不必再操心PO的状态问题了，对于他们来说，不管cat是new出来的对象，只是一个VO也好；还是从数据库查询出来的的PO对象也好，全部都是直接addMate就OK了： 

    代码

daoimple.addMate(cat, mate);