畢業設計總結（一） 資料庫概念 ： DO，DTO，dodto

畢業設計總結（一） 資料庫概念 ： DO，DTO，dodto

畢設告一段落，這一次畢設完全按照軟體工程流程進行，感觸良多，總結先不寫，先總結一下過程中出現的一些技術性問題，首先想說一下軟體設計實體的幾個概念。

實際上總共有四個概念： 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這類屬性。