项目经验分享：Hibernate与充血模型的“冲突”

“冲突”问题发生在将旧有项目进行充血模型改造的过程。我们给原有Bean的set方法中加入了业务逻辑（如上下文状态改变，事件触发等）。接下来程序的执行出问题了，症状五花八门但常常都是不可重现的问题。

通过好一番的代码走查，终于发现（意识到）Hibernate对于Bean的加载时，默认属性值的传递是使用bean的set方法的，这个时候触发了多余的业务逻辑处理。换句话说，这时候的充血模型与Hibernate的Bean加载“冲突"了。

解决"冲突"的方法很简单，将Bean配置为直接的属性访问（acess=feild）。

这样的Bug有时候是隐藏得比较深的。因为大部分的set方法是没有业务逻辑的，而且Hibernate的save行为发生在session.close的时候，如果一个bean在加载的时候，通过set方法隐形改变了另外一个Bean的状态，这时候session.close，就会把这种修改“悄悄的”保存，而不被程序员发觉。因为从业务代码上，程序只是读取了一个bean,没有做任何的修改动作，我的天～～～血泪教训啊！

希望看到这个帖子的同学，大家告诉大家！

学习了，感谢楼主！不过还从没有在bean的set方法中去加入业务逻辑！

怎么会在SET里加业务逻辑，相当犀利

中了充血模型的毒了

在setter中加逻辑，也应该式取值合法性验证才合理。这样hibernate也不应该引起bug

楼上的几位，把业务逻辑加在set中可不是本人发明的专利，你们可以look一下国外顶顶大明的开源JBPM的源码，他们就是这样做的啊～～～

再说，java的编程规范从来也没有规定不能在set中加业务逻辑啊！这个是设计的需要吧，当然也有个人习惯问题，但个人觉得没有好坏之分的。

这个帖子只是指出在hibernate使用中的一个问题，希望大家注意而已。因为这样的bug不容易发现，希望看到的同学们能注意，避免弯路