JavaBean之个人理解

JavaBean分为两种，其也能够称为POJO(Plain Ordinary Java Object)：

  一、VO(View Object)：值对象，主要用于封装页面上表单的数据；

  二、PO(Persisent Object)：持久化对象，主要用于封装数据库表中的数据，其取名通常为表名；

 

问题：

在SSH2开发中的数据前进过程，VO、POJO、PO之间的转换有什么好处？

若是这些O之间相互转换，我认为会增长如下问题：

一、属性拷贝增长了大量的工做量；

二、过多的对象转换带来性能上损失，而对象的内容几乎相同；

三、容易形成混淆，既然都是内容相同的对象，为什么不能使用一个，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必需要在性能、便于开发、便于维护之间找到一个平衡点。