java pojo

POJO（Plain Old Java Object）这种叫法是Martin Fowler、Rebecca Parsons和Josh MacKenzie在2000年的一次演讲的时候提出来的。
      我在做J2EE培训中发现我的很多学生问我什么是POJO，后来我在写书（《Spring2初学者实践教材》和《Spring3初学者实践教材》）的时候 发现POJO这个概念无法回避。现在网上对于POJO的解释很多，但是很多都是有错误的或者不够准确。对此我一开始也是存在误区的，我原来是这样理解的：
        POJO是这样的一种“纯粹的”JavaBean，在它里面除了JavaBean规范的方法和属性没有别的东西，即private属性以及对这个属性方法的public的get和set方法。我们会发现这样的JavaBean很“单纯”，它只能装载数据，作为数据存储的载体，而不具有业务逻辑处理的能力。
    所以下面的代码被认为是POJO了。

    package com.tongking.spring;

    public class DbHello implements Hello {

           private DictionaryDAO dao;

           public void setDao(DictionaryDAO dao) {

                  this.dao = dao;

           }

    }

        其实，这样的认为是错误的，我仔细阅读了《POJOs in Action》这本书的有关部分和POJO的最原始的出处，
        The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it''s caught on very nicely.

基本的意思是我们要给具有业务逻辑处理的规则的Java对象（regular java objects）起了一个名字——POJO，这些Java对象不是EntityBeans（EJB的一种）。

        我又在查到解释如下：

        , or Plain Old Java Object, is a normal class (that is, not a , EntityBean etc.)  and does not serve any other special role nor does it implement any special interfaces of any of the Java frameworks. This term was coined by Martin Fowler, Rebbecca Parsons and Josh MacKenzie who believed that by creating the acronym POJO, such objects would have a "fancy name", thereby convincing people that they were worthy of use.
        基本意思是说POJO一个正规的Java对象（不是JavaBean，EntityBean等），也不担当任何的特殊的角色，也不实现任何Java框架指定的接口。
        我觉得上面的解释很准确，POJO应该不是我们开始认为的JavaBean，当然更不是EJB，它不应该依赖于框架即继承或实现某些框架类或接口。例 如：Struts1中的Action和ActionForm当然不属于POJO了，而在Struts2中的Action由于可以不继承任何的接口，所以在 这种情况下Action是POJO，但是Struts2中的Action也可以继承ActionSupport类就不再属于POJO了。POJO里面是可 以包含业务逻辑处理和持久化逻辑，也可以包含类似与JavaBean属性和对属性访问的set和get方法的。
       最后，我们总结一下给一个定义吧，POJO是一个简单的、正规Java对象，它包含业务逻辑处理或持久化逻辑等，但不是JavaBean、EntityBean等，不具有任何特殊角色和不继承或不实现任何其它Java框架的类或接口。

---

O/R Mapping 是 Object Relational Mapping（对象关系映射）的缩写。通俗点讲，就是将对象与关系数据库绑定，用对象来表示关系数据。在O/R Mapping的世界里，有两个基本的也是重要的东东需要了解，即VO，PO。

PO：全称是 persistant object持久对象，一个PO对应于数据库中的一条记录，它是物理数据的对象表示。使用它，可以使我们的程序与物理数据解耦，并且可以简化对象数据与物理数据之间的转换。

VO：全称是 value object值对象，view object表现层对象，主要对应界面显示的数据对象。对于一个web页面、swing界面所显示的数据值就对应于一个VO，通常用于业务层之间的数据传 递，和PO一样也是仅仅包含数据而已。可以和表对应，也可以不，这根据业务的需要。

1．VO是用new关键字创建，由GC回收的。PO则是向数据库中添加新数据时创建，删除数据库中数据时削除的。并且它只能存活在一个数据库连接中，断开连接即被销毁。

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

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

有一种观点就是：PO只能用在数据层，VO用在商业逻辑层和表示层。各层操作属于该层自己的数据对象，这样就可以降低各层之间的耦合，便于以后系统的维护和扩展。如果将PO用在各个层中就相当于我们使用全局变量，我们知道在OO设计非常不赞成使用全局变量。

BO：

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

DTO ：

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

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

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

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

QO：查询对象
实体Model(实体模式)
DAL(数据访问层)
IDAL(接口层)
DALFactory(类工厂)
BLL(业务逻辑层)
BOF     Business Object Framework       业务对象框架
SOA     Service Orient Architecture     面向服务的设计
EMF     Eclipse Model Framework         Eclipse建模框架