毕设告一段落，这一次毕设完全按照软件工程流程进行，感触良多，总结先不写，先总结一下过程中出现的一些技术性问题，首先想说一下软件设计实体的几个概念。
实际上总共有四个概念： VO、DTO、DO、PO，根据我自己的理解，我只谈DTO和DO。但是下面贴出四个概念的解释：
（1） 概念解释
VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。
DTO（Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。
DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。
（2）DO
DO，Domain Object，我一般是放在Model包中，即作为项目的实体对象存在，往往是直接与ORM框架交互的类。
开发语言：java，支持数据库：Mysql 5，系统架构：J2EE，操作系统：linux/Windows1. 引言 32. 系统的结构 32.1 系统概述 33. 功能模块设计说明 43.1 商品管理 43.1.1 添加商品功能模块 53.1.2 商品列表功能模块 83.1.3 商品关联功能模块 93.
DO在实际开发中往往是一个POJO，提供了基本的Get/Set方法，方便进行数据操作，属性一般是以private为权限的，只有通过G/S方法才能对属性进行访问。直接与数据库进行交互的也是DO。
（3）DTO
DTO,Date Transfer Object，从字面意义上看就是数据传输类，实际上也确实如此，在服务器传到客户端的过程中，所需要的一个类的复杂度往往并不是数据库一个表可以搞定的，而是需要通过多重查询来拼装组合成一个结果。举个例子：
Project在前台进行呈现的时候可能需要提供ProjectName，UserName（项目名，所属人姓名），而在数据库中对应的Project表的字段可能是：ProjectId，UserId。单单查询Project表查询出来的只是User的一个Id而已，如果需要User的更多的信息则需要联合User表进行查询才可以，而DO中的Project类是不可能有这么详细且多样化的属性的，此时拼装出的数据应该放到ProjectDTO这个类中。举例代码如下：
1 public class Project{2 private String projectName;3 private String userid;
4 }1 public class User{2 private String username;3 private String userid;4 }public class ProjectDTO{ private String projectName; private User user;
}如此将ProjectDTO传到前台页面就可以取到合适的显示数据了，同时，由于是举例子，可能并不完善，实际应用之中，DTO中的User往往应该是UserDTO，因为User类中可能含有Password这类属性。
