Entity
最常用物體類，基本和資料表一一對應，一張表一個物體，
DAO（Data Access Object）：資料訪問物件
是sun公司的一個標準j2ee設計模式的介面之一，負責持久層的操作，Dao和其他的O區別最大，基本沒有互相轉化的可能性和必要，主要用來封裝對資料的訪問，而不是對資料庫的訪問，
PO（Persistant Object）：持久層物件
對應資料庫中表的欄位，資料庫中表中的記錄在java物件中的顯示狀態，即一個PO就是資料庫中的一條記錄，
BO（ business object）：業務物件
封裝業務邏輯為一個物件（可以包括多個PO，通常需要將BO轉換成PO，才能進行資料的持久化，反之，從DB中得到的PO，需要轉換成BO，才能在業務層中使用），
DTO（Data Transfer Object）：資料傳輸物件
前端呼叫時傳輸，也可以理解為“上層”呼叫時傳輸，
比如一張表有100個欄位，那么對應的PO就有100個屬性，但是我們界面上只要顯示10個欄位，客戶端用WEB service 來獲取資料，沒必要把整個PO物件傳到客戶端，這時我們就可以用只有這10個屬性的DTO來傳遞到客戶端，這樣也不會暴露服務端表結構，
VO（Value Object）：值物件
VO就是展示用的資料，不管展示方式是網頁，還是客戶端，還是App，只要這個東西是讓人看到的，就叫VO，VO主要的存在形式就是js中的物件（也可以簡單理解成json），
Pojo（Plain Ordinary Java Object）：純的傳統意義的java物件
最基本的javaBean只有屬性加上屬性的get和set方法，Pojo可以轉化為PO、DTO、VO，比如POJO在傳輸程序中就是DTO，
DO
DO跟上面其中一個概念相同，現在有兩個版本：
一個是阿里巴巴的開發手冊中的定義，DO（Data Object）等同于PO
另一個是在DDD（Domain-Driven Design）領域驅動設計中，DO（Domain Object），等同于BO，
一些實際的建議：
- PO不可省，不管叫PO還是Entity，
- 一些工具類的系統和一些業務不是很復雜的系統，DTO是可以和BO合并成一個，當業務擴展時注意拆分就行，
- VO是可以第一個優化掉的，展示業務不復雜的可以不要，直接用DTO，
- 多人協作時一定要保證大家的概念一致，
VO和DTO的區別
- 欄位不一樣，VO根據一些需要會刪減一些欄位
- 值不一樣，VO會根據需要對DTO中的值進行展示業務的解釋，
例子：
DTO可能是這樣的：
{
"gender":"男"，
"age":35
}
對于業務一來說，只需要性別，而且因為是一個古風聊天室，因此經過業務解釋業務一的VO是：
{
"gender":"公子"
}
對于業務二來說只需要年齡，而不需要精確的年齡，因此經過業務解釋業務二的VO是
{
"age":"30~39"
}
BO和DTO的區別
主要區別為欄位的刪減
BO對內，為了進行業務計算，需要輔助資料，或者是一個業務有多個對外的介面，BO可能會含有很多介面對外所不需要的資料，因此DTO需要在BO的基礎上，只要自己需要的資料，然后對外提供在這個關系上，通常不會有資料內容的變化，內容變化要么在BO內部業務計算的時候完成，要么在解釋VO的時候完成，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/282608.html
標籤：其他