資料庫概念 ： 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這類屬性。

以上是資料庫概念 ： DO，DTO的詳細內容。更多資訊請關注PHP中文網其他相關文章！