SpringMVC+mybatis+jQueryEasyUI网站开发之路

PO(persistant object) 持久对象：PO是只含有get/set方法的POJO

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

它们是由一组属性和属性的get和set方法组成。可以看成是与数据库中的表相映射的java对象

Service:

service层是在mcv三层模式中新添加一层，能够更加清晰的定义应用程序的边界，需要操作数据的时候，通过service层访问DAO层来实现。service层做的事情，不仅仅是调用DAO操作数据，还会包含了一定的业务逻辑。整个程序的设计，也变成了针对服务进行设计。

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

主要用在前段数据和控件的绑定操作中，以键值对的形式存在。可以从DTO转化而来，这么做的好处就是减少对于DTO的依赖，进一步减少对应后端的依赖。还可以增加前段的可测试性，也就是没有DTO，也可以对前段逻辑进行自动化的单元测试，可以通过MockDTO来达到测试的目的。

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

个人感觉POJO是最参见最多变的对象，是一个中间对象，也是我们最常打交道的对象。一个POJO持久化以后就是PO直接用它传递、传递过程中就是DTO直接用来对应表示层就是VOBO：Business Object，业务对象。主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。比如一个简历，有教育经历、工作经历、社会关系等等。我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。建立一个对应简历的BO对象处理简历，每个BO包含这些PO。这样处理业务逻辑时，我们就可以针对BO去处理。

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

负责将PO持久化到数据库，也负责将从数据库查询的结果集映射为PO。这个大家最熟悉，基本没有互相转化的可能性和必要.主要用来封装对数据库的访问。通过它可以把POJO持久化为PO，用PO组装出来VO、DTO

DTO (Data TransferObject)数据传输对象：

DTO是展示层和服务层之间的数据传输对象（可以认为是两者之间的协议）一般用来在前段和后台的数据传输

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

VO与DTO的区别        大家可能会有个疑问（在笔者参与的项目中，很多程序员也有相同的疑惑）：既然DTO是展示层与服务层之间传递数据的对象，为什么还需要一个VO呢？对！对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，因此没必要多此一举，但不要忘记这是实现层面的思维，对于设计层面来说，概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。        用一个例子来说明可能会比较容易理解：例如服务层
b29f
有一个getUser的方法返回一个系统用户，其中有一个属性是gender(性别)，对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。说到这里，可能你还会反驳，在服务层直接就返回“帅哥美女”不就行了吗？对于大部分应用来说，这不是问题，但设想一下，如果需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO，不应该出现与表现形式的耦合。  理论归理论，这到底还是分析设计层面的思维，是否在实现层面必须这样做呢？一刀切的做法往往会得不偿失，下面我马上会分析应用中如何做出正确的选择。
VO与DTO的应用        上面只是用了一个简单的例子来说明VO与DTO在概念上的区别，本节将会告诉你如何在应用中做出正确的选择。        在以下才场景中，我们可以考虑把VO与DTO二合为一（注意：是实现层面）： 当需求非常清晰稳定，而且客户端很明确只有一个的时候，没有必要把VO和DTO区分开来，这时候VO可以退隐，用一个DTO即可，为什么是VO退隐而不是DTO？回到设计层面，服务层的职责依然不应该与展示层耦合，所以，对于前面的例子，你很容易理解，DTO对于“性别”来说，依然不能用“帅哥美女”，这个转换应该依赖于页面的脚本（如JavaScript）或其他机制（JSTL、EL、CSS） 
即使客户端可以进行定制，或者存在多个不同的客户端，如果客户端能够用某种技术（脚本或其他机制）实现转换，同样可以让VO退隐以下场景需要优先考虑VO、DTO并存： 因为某种技术原因，比如某个框架（如Flex）提供自动把POJO转换为UI中某些Field时，可以考虑在实现层面定义出VO，这个权衡完全取决于使用框架的自动转换能力带来的开发和维护效率提升与设计多一个VO所多做的事情带来的开发和维护效率的下降之间的比对。 如果页面出现一个“大视图”，而组成这个大视图的所有数据需要调用多个服务，返回多个DTO来组装（当然，这同样可以通过服务层提供一次性返回一个大视图的DTO来取代，但在服务层提供一个这样的方法是否合适，需要在设计层面进行权衡）。

获取数据的过程：首先DAO从数据库获取结果集，转换为PO。Domain接受到DAO传递过来的PO之后，负责将PO转换为BO，再进行业务逻辑的处理。处理完毕，传递BO给service，service负责转换为DTO，传输给前端接收到DTO之后，首先转换为VO，然后再进行前端的业务处理。提交数据的过程： 前端将数据整理为DTO，传输给service，service转换为BO传输给Domain，Domain转换为PO，调用DAO提供的数据持久化方法，持久化PO，DAO负责将PO持久化为数据库的数据。

在 struts+spring+hibernate 的系统中，
对象的调用流程是： jsp-> Action － > Service ->DAO ->Hibernate 。
数据的流向是 ActionFormBean 接受用户的数据， Action 将数据从 ActionFromBean 中取出，封装成 VO 或 PO,
再调用业务层的 Bean 类，完成各种业务处理后再 forward 。而业务层 Bean 收到这个 PO 对象之后，会调用 DAO 接口方法，进行持久化操作。