前言
以前在学校学习java的时候，凡是开发项目都会将各个类分门别类的放在不同的包下，其中实体类的包尤为普遍，一般我都是建一个com.xxx.bean的包，然后凡是项目里面用到的实体类都丢进去，大家都是这样，也就习惯了。
到了公司，接触项目后，发现在bean包下面还会分很多包，比如vo/dto/po等，怕自己建类时贻笑大方，特此学习并记录。
PO（bean,entity等命名）：
persistant object持久对象
数据库表中的记录在java对象中的显示状态
最形象的理解就是一个PO就是数据库中的一条记录。
好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。
BO（service,manager,business等命名）：
business object业务对象
主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。
形象描述为一个对象的形为和动作，当然也有涉及到基它对象的一些形为和动作。比如处理
一个人的业务逻辑，有睡觉，吃饭，工作，上班等等形为以及和别人有关系的行为。
这样处理业务逻辑时，我们就可以针对BO去处理。
VO（from也有此写法） ：
value object值对象
主要体现在视图的对象，对于一个WEB页面将整个页面的属性封装成一个对象。然后用一个VO对象在控制层与视图层进行传输交换。
PO和VO的区别
它们是由一组属性和属性的 get 和 set 方法组成。从结构上看，它们并没有什么不同的地方。但从其意义和本质上来看是完全不同的。
- VO 是用 new 关键字创建，由 GC 回收的。 PO 则是向数据库中添加新数据时创建，删除数据库中数据时削除的。并且它只能存活在一个数据库连接中，断开连接即被销毁。
- VO 是值对象，精确点讲它是业务对象，是存活在业务层的，是业务逻辑使用的，它存活的目的就是为数据提供一个生存的地方。 PO 则是有状态的，每个属性代表其当前的状态。它是物理数据的对象表示。使用它，可以使我们的程序与物理数据解耦，并且可以简化对象数据与物理数据之间的转换。
- VO 的属性是根据当前业务的不同而不同的，也就是说，它的每一个属性都一一对应当前业务逻辑所需要的数据的名称。 PO 的属性是跟数据库表的字段一一对应的。 PO 对象需要实现序列化接口。
DTO (经过处理后的PO，可能增加或者减少PO的属性)：
Data Transfer Object数据传输对象
主要用于远程调用等需要大量传输对象的地方。
比如我们一张表有100个字段，那么对应的PO就有100个属性。
但是我们界面上只要显示10个字段，
客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，
这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO
POJO（POJO是一种概念或者接口，身份及作用随环境变化而变化） ：
POJO有一些private的参数作为对象的属性。然后针对每个参数定义了get和set方法作为访问的接口
plain ordinary java object 简单java对象
即POJO是一个简单的普通的Java对象，它不包含业务逻辑或持久逻辑等，但不是JavaBean、EntityBean等，不具有任何特殊角色和不继承或不实现任何其它Java框架的类或接口。
POJO对象有时也被称为Data对象，大量应用于表现现实中的对象。
一个POJO持久化以后就是PO。
直接用它传递、传递过程中就是DTO
直接用来对应表示层就是VO
DAO（data access object数据访问对象）：
这个大家最熟悉，和上面几个O区别最大，基本没有互相转化的可能性和必要.
主要用来封装对数据库的访问。通过它可以把POJO持久化为PO，用PO组装出来VO、DTO
Controller 控制层主要是action/servlet等构成（目前Spring mvc则是通过@Controller标签使用）
此层业务层与视图层打交道的中间层，负责传输VO对象和调用BO层的业务方法，负责视图层请求的数据处理后响应给视图层。
view（视图层）
主要是指由jsp,html等文件形成的显示层。
总结一下要用具体的X0需要看具体环境及项目架构，在不同的层、不同的应用场合，对象的身份也不一样，而且对象身份的转化也是很自然的。就像你对老婆来说就是老公，对父母来说就是子女。设计这些概念的初衷不是为了唬人而是为了更好的理解和处理各种逻辑，让大家能更好的去用面向对象的方式处理问题。
在平时开发项目中大家千万过度设计各层，因为这样会带来大量的工作和重复工作。如果不是大型系统可简化一些层，因为技术是为应用服务的。
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
