PO是持久化对象，它只是将物理数据实体的一种对象表示，为什么需要它？因为它可以简化我们对于物理实体的了解和耦合，简单地讲，可以简化对象的数据转换为物理数据的编程。VO是什么？它是值对象，准确地讲，它是业务对象，是生活在业务层的，是业务逻辑需要了解，需要使用的，再简单地讲，它是概念模型转换得到的。FormBean又是什么？它只是HTML表单的封装，是为了在控制层弱化request中存储数据的作用，将request的get方法转变为对象的存取值。
理清了上述概念，好，我们就开始讨论，为什么需要它们，为什么不需要它们。首先说PO和VO吧，它们的关系应该是相互独立的，一个VO可以只是PO的部分，也可以是多个PO构成，同样也可以等同于一个PO（当然我是指他们的属性）。正因为这样，PO独立出来，数据持久层也就独立出来了，它不会受到任何业务的干涉。又正因为这样，业务逻辑层也独立开来，它不会受到数据持久层的影响，业务层关心的只是业务逻辑的处理，至于怎么存怎么读交给别人吧！不过，另外一点，如果我们没有使用数据持久层，或者说没有使用hibernate，那么PO和VO也可以是同一个东西，虽然这并不好。其次，让我们看看FormBean和VO，如果简单地讲，我们是可以不需要FormBean的，它只是struts带来的一部分，而VO是无论如何不能舍弃的。如果让FormBean直接到业务层（它本来应该生活在控制层），那么会带来什么？View和Model就出现了强耦合，如果想改一下view的表示，整个业务逻辑都得改，恐怖的事情啊！
理清了上述概念，好，我们就开始讨论，为什么需要它们，为什么不需要它们。首先说PO和VO吧，它们的关系应该是相互独立的，一个VO可以只是PO的部分，也可以是多个PO构成，同样也可以等同于一个PO（当然我是指他们的属性）。正因为这样，PO独立出来，数据持久层也就独立出来了，它不会受到任何业务的干涉。又正因为这样，业务逻辑层也独立开来，它不会受到数据持久层的影响，业务层关心的只是业务逻辑的处理，至于怎么存怎么读交给别人吧！不过，另外一点，如果我们没有使用数据持久层，或者说没有使用hibernate，那么PO和VO也可以是同一个东西，虽然这并不好。其次，让我们看看FormBean和VO，如果简单地讲，我们是可以不需要FormBean的，它只是struts带来的一部分，而VO是无论如何不能舍弃的。如果让FormBean直接到业务层（它本来应该生活在控制层），那么会带来什么？View和Model就出现了强耦合，如果想改一下view的表示，整个业务逻辑都得改，恐怖的事情啊！
这些对象概念的出现其实就是体现了一种层的思维，也是体现了一种框架的思维，在层与层之间我们需要什么？我们应该怎么通信，其实大家认真地用笔画上几个图就可以知道了。做web应用尤其是企业应用，切忌像楼上某些朋友说的，一个东东从头到尾，那是非常低劣和错误的设计。我们不要单纯地就为了某些对象去争论什么，它们更多的只是思维。这样的思维给我们带来了哪些好处，不言自明，当然，我们也不得不否认，我们因此失去了某些东西，比如局部的性能或者繁琐的代码和调用过程，只是自己衡量一下，它是否值得。
本文转自sucre03 51CTO博客，原文链接：http://blog.51cto.com/sucre/360030，如需转载请自行联系原作者
