数据库概念 ： DO，DTO

毕设告一段落，这一次毕设完全按照软件工程流程进行，感触良多，总结先不写，先总结一下过程中出现的一些技术性问题，首先想说一下软件设计实体的几个概念。

实际上总共有四个概念： 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框架交互的类。

　　

　　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这类属性。

转载于:https://www.cnblogs.com/makeitworth/p/6988848.html