數據庫概念 ： 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這個類中。舉例代碼如下：

　　

public class Project{
      private String projectName;
      private String userid;      
}

public class User{
    private String username;
    private String userid;
}

public class ProjectDTO{
     private String projectName;
     private User user;
}

如此將ProjectDTO傳到前台頁面就可以取到合適的顯示數據了，同時，由於是舉例子，可能並不完善，實際應用之中，DTO中的User往往應該是UserDTO，因為User類中可能含有Password這類屬性。