java术语（PO/POJO/VO/BO/DAO/DTO）

[size=x-large][b][color=red][align=center]java术语(PO/POJO/VO/BO/DAO/DTO)[/align][/color][/b][/size]

[color=red]导语：我们大可不必在对象的名称和叫法上过分纠结。因为对于程序员来说，无论这些对象被冠以什么样花里胡哨的名称，它们只不过是对基本的、运行在JavaBean模式下对象的有效扩展或增强，各种不同的对象名称的定义，它们之间的界定实际上是非常模糊的。同样一个对象，往往可以兼任多种不同的角色，在不同的编程层次表现为不同的对象实体，其最终目的是特定的场合表现出其作用。 [/color]

[size=medium][b][color=green]PO(persistant object) 持久对象[/color][/b][/size]
在o/r 映射的时候出现的概念,如果没有o/r映射,就没有这个概念存在了.通常对应数据模型(数据库),本身还有部分业务逻辑的处理.可以看成是与数据库中的表相映射的java对象.最简单的PO就是对应数据库中某个表中的一条记录,多个记录可以用PO的集合.PO中应该不包含任何对数据库的操作.

[size=medium][b][color=green]VO(value object) 值对象[/color][/b][/size]
通常用于业务层之间的数据传递,和PO一样也是仅仅包含数据而已.但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.个人觉得同DTO(数据传输对象),在web上传递.

[size=medium][color=green][b]BO(business object) 业务对象[/b][/color][/size]
从业务模型的角度看,见UML元件领域模型中的领域对象.封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作.

[size=medium][color=green][b]POJO(plain ordinary java object) 简单无规则java对象[/b][/color][/size]
纯 的传统意义的java对象.就是说在一些Object/Relation Mapping工具中,能够做到维护数据库表记录的persisent object完全是一个符合Java Bean规范的纯Java对象,没有增加别的属性和方法.我的理解就是最基本的Java Bean,只有属性字段及setter和getter方法!.

[size=medium][color=green][b]DAO(data access object) 数据访问对象[/b][/color][/size]
是sun的一个标准j2ee设计模式,这个模式中有个接口就是DAO,它负责持久层的操作.为业务层提供接口.此对象用于访问数据库.通常和PO结合使用,DAO中包含了各种数据库的操作方法.通过它的方法,结合PO对数据库进行相关的操作.夹在业务逻辑与数据库资源中间.配合VO, 提供数据库的CRUD操作...

[size=medium][color=green][b]DTO (Data Transfer Object)数据传输对象[/b][/color][/size]
主要用于远程调用等需要大量传输对象的地方。
比如我们一张表有100个字段，那么对应的PO就有100个属性。
但是我们界面上只要显示10个字段，
客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，
这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO

O/R Mapper 对象/关系 映射
定义好所有的mapping之后,这个O/R Mapper可以帮我们做很多的工作.通过这些mappings,这个O/R Mapper可以生成所有的关于对象保存,删除,读取的SQL语句,我们不再需要写那么多行的DAL代码了.
实体Model(实体模式)
DAL(数据访问层)
IDAL(接口层)
DALFactory(类工厂)
BLL(业务逻辑层)
BOF Business Object Framework 业务对象框架
SOA Service Orient Architecture 面向服务的设计
EMF Eclipse Model Framework Eclipse建模框架





J2EE开发中大量的专业缩略语很是让人迷惑，尤其是跟一些高手讨论问题的时候，三分钟就被人家满口的专业术语喷晕了，PO VO BO DTO POJO DAO，一大堆的就来了（听过老罗对这种现象的批判的朋友会会心一笑）。

首先声明偶也不是什么高手，以下总结都是自己的体会。不对之处请您多指教。

PO：
persistant object持久对象

最形象的理解就是一个PO就是数据库中的一条记录。
好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。




--------------------------------------------------------------------------------


BO：
business object业务对象

主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。
比如一个简历，有教育经历、工作经历、社会关系等等。
我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。
建立一个对应简历的BO对象处理简历，每个BO包含这些PO。
这样处理业务逻辑时，我们就可以针对BO去处理。




--------------------------------------------------------------------------------


VO ：
value object值对象
ViewObject表现层对象

主要对应界面显示的数据对象。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值。




--------------------------------------------------------------------------------


DTO ：
Data Transfer Object数据传输对象
主要用于远程调用等需要大量传输对象的地方。
比如我们一张表有100个字段，那么对应的PO就有100个属性。
但是我们界面上只要显示10个字段，
客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，
这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO




--------------------------------------------------------------------------------


POJO ：
plain ordinary java object 简单ava对象
个人感觉POJO是最参见最多变的对象，是一个中间对象，也是我们最常打交道的对象。

一个POJO持久化以后就是PO
直接用它传递、传递过程中就是DTO
直接用来对应表示层就是VO





--------------------------------------------------------------------------------

DAO：
data access object数据访问对象
这个大家最熟悉，和上面几个O区别最大，基本没有互相转化的可能性和必要.
主要用来封装对数据库的访问。通过它可以把POJO持久化为PO，用PO组装出来VO、DTO


总结下我认为一个对象究竟是什么O要看具体环境，在不同的层、不同的应用场合，对象的身份也不一样，而且对象身份的转化也是很自然的。就像你对老婆来说就是老公，对父母来说就是子女。设计这些概念的初衷不是为了唬人而是为了更好的理解和处理各种逻辑，让大家能更好的去用面向对象的方式处理问题.

大家千万不要陷入过度设计，大可不必为了设计而设计一定要在代码中区分各个对象。一句话技术是为应用服务的。

欢迎指正。

po是persistent object，是在是orm框架中的entity，po的每个属性基本上都对应数据库表里面的某个字段。

vo(value object)有时可以跟po一样，有时并不对应，可以属性比PO多,通过用户new创建，由gc()回收
vo(view object):struts1里的BeanForm，用户访问容器自动创建植入数据。
bindEntity(currentForm, vo);//将查询条件从form中复制到实体exampleVO中

POJO（Plain Old Java Objects）是简单java对象，他并不继承任何类（继承Object），实现任何接口，只有属性跟get set方法。而po一般要实现序列化接口，有时也继承一些类。

                                                            O/R Mapping:Object Relational Mapping

将对象与关系数据库绑定，用对象来表示关系数据。


VO:Value Object值对象

PO:Persisent Object持久对象


由一组属性和属性的get和set方法组成


1.VO是用new关键字创建，由GC回收的

PO是向数据库中添加新数据时创建，删除数据库中的数据时削除的。并且只能存活在一个数据库连接中，断开连接即被销毁


2.VO是值对象，业务对象，存活在业务层，是业务逻辑使用的，存活的目的就是为数据提供一个生存的地方。PO则是有状态的，每个属性代表其当前的状态。它是物理数据的对象表示。使用它，可以使我们的程序与物理数据解耦，并且可以简化对象数据与物理数据之间的转换。


3.VO的属性是根据当前业务的不同而不同的，也就是说，它的每一个属性都一一对应当前业务逻辑所需要的数据的名称。PO的属性是跟数据库表的字段一一对应的。


PO对象需要实现序列化接口


------------------------------


PO是持久化对象，它只是将物理数据实体的一种对象表示，可以简化我们对于物理实体的了解和耦合，可心简化对象的数据转换为物理数据的编程。VO是值对象，是业务对象，是生活在业务层的，是业务逻辑需要了解，需要使用的，再简单地讲，安是概念模型转换得到的。

PO和VO，它们的关系应该是相互独立的，一个VO可以只是PO的部分，也可以是多个PO构成，同样也可以等同于一个PO（属性）。正因为这样，PO独立出来，数据持久层也就独立出来了，它不会受到任何业务的干涉。又正因为这样，业务逻辑层也独立开来，它不会受到数据持久层的影响，业务层关心的只是业务逻辑的处理。如果我们没有使用数据持久层，或者说没有使用hibernate，那么PO和VO也可以是同一个东西，虽然这并不好。


------------------------------------


PO(persistant object)持久对象

在o/r映射的时候出现的概念，如果没有o/r映射，没有这个概念存在了。通常对应数据模型（数据库），本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中的某个表中的一条记录，多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作。


VO(value object)值对象

通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象，可以和表对应，也可以不，这根据业务的需要，个人觉得同DTO（数据传输对象），在web上传递。


TO（Transfer Object）数据传输对象

在应用程序不能tie（关系）之间传输的对象


BO(business object)业务对象

从业务模型的角度看，见UML元件领域模型中的领域对象。封装业务

转自：[url]http://www.cnblogs.com/sunwei2012/archive/2009/12/31/1636771.html[/url]