JavaBean分为两种，其也可以称为POJO(Plain Ordinary Java Object)：
1、VO(View Object)：值对象，主要用于封装页面上表单的数据；
2、PO(Persisent Object)：持久化对象，主要用于封装数据库表中的数据，其取名一般为表名；
问题：
在SSH2开发中的数据前进过程，VO、POJO、PO之间的转换有什么好处？
如果这些O之间相互转换，我认为会增加以下问题：
1、属性拷贝增加了大量的工作量；
2、过多的对象转换带来性能上损失，而对象的内容几乎相同；
3、容易造成混淆，既然都是内容相同的对象，为何不能使用一个，POJO就能代替大部分O，各个O之间相互转换的好处是什么？
回答：
VO(View Object)：值对象，用于封装界面数据。POJO：类似于JavaBean的java类。
PO(Persisent Object)：持久化对象，也就是数据库表对应的类，主要是为了分离层与层之间的耦合性。
首先应该遵守的原则：
一个界面最好对应一个VO类，而不应该向界面传很多对象或List，用于显示或获取界面中的参数。一个数据库表对应一个PO类，而其他地方需要额外用到的类就是POJO了。
举例：我需要在界面上显示所有的角色，点击角色选择角色下的所有用户，那么这个界面的数据类，也就是VO，应该包含三个元素：所有的角色，选择的角色，所选角色的用户，转换为VO对象就是：List<角色>、角色、List<用户>，这些数据涉及到两个PO类，也就是角色和用户，我们可以在后台根据业务需求876913451进行获取。那为什么会出现VO类，我直接把需要的所有数据，比如List<角色>、角色、List<用户>通过request传到界面上不就行了？这样从实现功能上说没有问题，但是假如把你写的程序给你别人看，别人乍一看，他知道你向界面传了多少对象？难道他必须要从头到尾看一遍你的业务逻辑代码吗？想想你在业务代码中这儿向request中传huiny30347121一个对象，那儿又传一个对象，这样很不现实，不利于二次开发(而大多数软件都是需要进行二次开发的)，也不利于因为客户需求的变化改代码，而且最主要的是，这样不能体现面向对象思想，对于一系列数据，我们应该封装成一个类，这是基本的封装思想。
至于属性的拷贝：相对于你后期需要改代码时的痛苦来说，这样写更清晰，更好，不是吗？
对象转换上的性能损失：相对于B/S系统来说，制约用户访问速度的关键因素应该是网速吧，也就是客户端和服务器端的数据交换。但你可能会说，那为什么数据库经常提到性能问题呢，因为数据库有时需要处理几十万条数据，假如你的sql语句写的不精练的话，用户点一下按钮，可能多等待几十秒。但是对象转换不可能带来太多的影响，对吧！最后，假如你怕对象转换带来性能损失，那你就写一个对象得了，所有的代码都在里面写，这样好吗？所以，我们277413318必须要在性能、便于开发、便于维护之间找到一个平衡点。