谈到VO马上就会想到与之相关的PO。
PO一般都数据库的直接映射，如hibernate（当然是个代理类，不细解析）
我以前曾经对VO的使用。
一、直接用hibernate 实体类做VO类型，即PO与VO同属于同一个类。
二、以前用struts1.1的时候，用formbean作为VO类，即在hibernate中把PO转成formbean,让formbean到前台展现。
我现在我又有一个新的设计观点，因为使用struts2：
把hibernate的实体类作为父类，VO继承实体类。
为什么这样做呢，先对之前二种做法的缺点说明一下：
第一种，把实体类又作为VO类，即把UI层特殊的展示需要增加实体的域来体现，这样就相关于弄脏了原来纯净的实体，如果采用分层开发话，web开发人员与后台业务开发人员相关把同一个java类不停的更改，时间久了很难管理。
第二种，采用struts1或者在webwork,struts2中增加一个与实体一样的java类做为vo,这样做是一点问题没有，不过大部份情况下po,vo各内容完全一样，或者大部份一样，再去写一套这样的一层，更是感觉完全没有什么意思，否则webwork,与struts2这样的web框架弄出来有什么意思啊，还不如用struts1.
第三个理由是，我在各个层之间之前都是采用实体来进行传参数，如action->service,saveUser(user),find(user),service->dao...现在这种设计，特别是为find(user),list(user)等方法，把实体传进去，然后在dao中组装在hql,sql或者其它。在做查询条件时又往往只有实现一个不能满足能组装的条件查询，如user中有一个birthday，如想查询2003.7 至2004.7之间生日的人，用实体肯定不能把这二个条件包含进去，所以也采用继承实体来进行处理。
还如一点，如果更需要精细话的设计，那么也可以把service中传递的值继承实体类，在web中的展现ui的实体承继service中传递值的类
PO一般都数据库的直接映射，如hibernate（当然是个代理类，不细解析）
我以前曾经对VO的使用。
一、直接用hibernate 实体类做VO类型，即PO与VO同属于同一个类。
二、以前用struts1.1的时候，用formbean作为VO类，即在hibernate中把PO转成formbean,让formbean到前台展现。
我现在我又有一个新的设计观点，因为使用struts2：
把hibernate的实体类作为父类，VO继承实体类。
为什么这样做呢，先对之前二种做法的缺点说明一下：
第一种，把实体类又作为VO类，即把UI层特殊的展示需要增加实体的域来体现，这样就相关于弄脏了原来纯净的实体，如果采用分层开发话，web开发人员与后台业务开发人员相关把同一个java类不停的更改，时间久了很难管理。
第二种，采用struts1或者在webwork,struts2中增加一个与实体一样的java类做为vo,这样做是一点问题没有，不过大部份情况下po,vo各内容完全一样，或者大部份一样，再去写一套这样的一层，更是感觉完全没有什么意思，否则webwork,与struts2这样的web框架弄出来有什么意思啊，还不如用struts1.
第三个理由是，我在各个层之间之前都是采用实体来进行传参数，如action->service,saveUser(user),find(user),service->dao...现在这种设计，特别是为find(user),list(user)等方法，把实体传进去，然后在dao中组装在hql,sql或者其它。在做查询条件时又往往只有实现一个不能满足能组装的条件查询，如user中有一个birthday，如想查询2003.7 至2004.7之间生日的人，用实体肯定不能把这二个条件包含进去，所以也采用继承实体来进行处理。
还如一点，如果更需要精细话的设计，那么也可以把service中传递的值继承实体类，在web中的展现ui的实体承继service中传递值的类
