做个调查：有必要另起一个vo吗？还是用pojo直接当做vo使用？

的确是，目前在项目中基本上不分POJO和VO，把它们合成了一个，需要时在POJO中增加一些处理分别为前台和数据服务就可以了

分层的架构中，层与层之间解耦是不可能的。除非我们理解的耦合不是一个意思。
单独弄出一个vo的意义在于，当pojo被多个页面，甚至不同业务重复使用的时候，可以避免view specific的逻辑被暴露给不需要的模块。这也是解耦和，但是不是层与层之间的耦合，而是页面与页面之间，业务与业务之间的解耦和。

我们项目平常一般是直接用PO.
但是如果遇到报表展示之类的需求,首先要在后台从多个PO中取出数据,
放到一个VO在前台展现.
感觉VO和PO什么时候用得看具体情况,
很多情况可以直接用PO.开发效率比较快,也不容易出错

我们项目也一直延续着简单为主的概念，一直使用着VO，因为我们一直使用者struts1.2中ACTIONFORM,为了页面的中一些简单赋值等动作，忽略了PO。现在项目到了尾端，但是，存在了许多弊端：
1、代码维护性下降。
2、VO层根本没有OO的概念，业务中的耦合度增加。
目前的解决方案：
VO == POJO ? VO：（多个POJO+转化接口=VO）

  赞同此观点

前端跟后端走，不是后端根据前端设计。要不然页面随便一改，逻辑还没改就改秃噜了。

前端能直接用后端的就直接用，不能的就自己搞个出来。不就完了么。

vo应该需要的，vo po的转换也没有那么复杂，使用工具自动生成vo以及vo po的mapping

弱弱的问下，什么是PO，什么是VO？什么又是JavaBean？

抛哥说的有道理啊，VO继承PO。具体原因你问抛哥吧，他应该比我知道。

说的好，VO，PO 不过是在不同层次中的不同叫法。
到底是分成两个，还是一个就够了，看实际情况被。
没必要每个都分，也没必要全部都合在一起。

概念是死的，人是活的，好与不好是看如何运用，和产生的结果，
光谈概念没意义。