Java中 VO、 PO、DO、DTO、 BO、 QO、DAO、POJO之dozer mapper使用
PO(persistant object) 持久物件
在 o/r 對映的時候出現的概念，如果沒有 o/r 對映，沒有這個概念存在了。通常對應資料模型 ( 資料庫 ), 本身還有部分業務邏輯的處理。可以看成是與資料庫中的表相對映的 java 物件。最簡單的 PO 就是對應資料庫中某個表中的一條記錄，多個記錄可以用 PO 的集合。 PO 中應該不包含任何對資料庫的操作。
DO（Domain Object）領域物件
就是從現實世界中抽象出來的有形或無形的業務實體。一般和資料中的表結構對應。
TO(Transfer Object) ，資料傳輸物件
在應用程式不同 tie( 關係 ) 之間傳輸的物件
DTO（Data Transfer Object）資料傳輸物件
這個概念來源於J2EE的設計模式，原來的目的是為了EJB的分散式應用提供粗粒度的資料實體，以減少分散式呼叫的次數，從而提高分散式呼叫的效能和降低網路負載，但在這裡，我泛指用於展示層與服務層之間的資料傳輸物件。
VO(view object) 值物件
檢視物件，用於展示層，它的作用是把某個指定頁面（或元件）的所有資料封裝起來。
BO(business object) 業務物件
從業務模型的角度看 , 見 UML 元件領域模型中的領域物件。封裝業務邏輯的 java 物件 , 通過呼叫 DAO 方法 , 結合 PO,VO 進行業務操作。 business object: 業務物件 主要作用是把業務邏輯封裝為一個物件。這個物件可以包括一個或多個其它的物件。 比如一個簡歷，有教育經歷、工作經歷、社會關係等等。 我們可以把教育經歷對應一個 PO ，工作經歷對應一個 PO ，社會關係對應一個 PO 。 建立一個對應簡歷的 BO 物件處理簡歷，每個 BO 包含這些 PO 。 這樣處理業務邏輯時，我們就可以針對 BO 去處理。
POJO(plain ordinary java object) 簡單無規則 java 物件
純的傳統意義的 java 物件。就是說在一些 Object/Relation Mapping 工具中，能夠做到維護資料庫表記錄的 persisent object 完全是一個符合 Java Bean 規範的純 Java 物件，沒有增加別的屬性和方法。我的理解就是最基本的 Java Bean ，只有屬性欄位及 setter 和 getter 方法！。
DAO(data access object) 資料訪問物件
是一個 sun 的一個標準 j2ee 設計模式， 這個模式中有個介面就是 DAO ，它負持久層的操作。為業務層提供介面。此物件用於訪問資料庫。通常和 PO 結合使用， DAO 中包含了各種資料庫的操作方法。通過它的方法 , 結合 PO 對資料庫進行相關的操作。夾在業務邏輯與資料庫資源中間。配合 VO, 提供資料庫的 CRUD 操作
在Web開發中，我們會接觸到很多領域模型中的概念，其中大部分和實體相關的概念都有縮寫，一般以O（Object）結尾。其中比較常見的由DO、DTO、VO、DAO等。我們也經常有把一個實體物件轉換為另外一個實體物件的操作。本文主要是介紹一種作者在實踐中總結的一種自認為比較優雅的轉換方式。歡迎拍磚。
什麼是DO、DTO和VO
在Java中 VO、 PO、DO、DTO、 BO、 QO、DAO、POJO的概念中介紹過Java中的各種模型概念。
在這裡簡單再總結一下：
在日常的專案開發中，
VO對應於頁面上需要顯示的資料（表單），DO對應於資料庫中儲存的資料（資料表），DTO對應於除二者之外需要進行傳遞的資料。
很多人可能對VO和DTO並不是那麼熟悉，相反對DO卻比較熟悉，那是因為在很多專案中由於種種原因我們只使用了DO，原因可能有以下幾種：
1、專案太小，對於一種業務實體，封裝成一個DO就夠了。
2、並不熟悉DTO、VO，更不知道他們之間的區別。
3、瞭解DO\DTO\VO之間的區別，但是懶得用。
那麼，這裡，博主再囉嗦一下為什麼要引入這麼多概念，為什麼我要建議大家在自己的專案中使用這些實體物件。
為什麼不能只用一個DO
我們來看這樣一個例子。假如我們的專案中由User這樣一個實體。我們在建立User表的時候一般包含一下屬性：
針對這個實體，我們通常需要建立一個DO類，用來封裝這個User實體。
public class UserDO {
private Integer id; //唯一主鍵
private Date createdTime; //建立時間
private Date updatedTime; //最後更新時間
private String name; //姓名
private Integer age; //年齡
private String gender; //性別
private String address; //住址
private String password; //密碼
private String nickName; //暱稱
private Date birthday; //生日
private String politicalStatus; //政治面貌,1表示群眾,2表示團員,3表示黨員,4表示其他,100表示未知
private Integer companyId; //公司的ID
private Integer status; //資料狀態,1表示可用,0表示不可用
//setter and getter
}然後，在程式碼中，從DAO一直到前端展示，我們都通過這個UserDO類的物件來進行資料傳輸。這樣做會有什麼問題嘛？
-
不需要的欄位也會傳遞到前端頁面。
- 如password、createdTime、updatedTime和status這幾個欄位我們可能在前端根本不需要展示，但是這些欄位有可能也會被傳遞到前端（除非我們在SQL查詢的時候沒有查詢出對應的欄位）。這不僅使資料的傳輸量增大，還可能有安全性問題。
-
某些欄位需要轉換，但是無法支援。
- 對於上面例子中的政治面貌欄位，我們在資料庫中儲存的是數字，但是在前端頁面我要展示的是中文描述。這種情況只能在前端通過
if/else的方式來分情況展示。
- 對於上面例子中的政治面貌欄位，我們在資料庫中儲存的是數字，但是在前端頁面我要展示的是中文描述。這種情況只能在前端通過
-
某些欄位要展示，但是並不希望出現在資料庫中
- 在User表中我們只儲存了這個使用者的companyId，需要同時查詢company表來查詢出該公司的更多詳細資訊。對於User物件，如果我們想在前端同時展示他所屬的公司，希望通過一次查詢全都查出來怎麼辦？有幾個簡單的方案，第一個是讓UserDO中包含一個Company類的屬性，通過這個屬性來傳遞。另外一種是把我們希望傳到前端的Company的屬性也寫到UserDO中。但是，如果真的這麼做了，那UserDO還能被稱作DO了嗎？
還有很多問題，這這裡就不詳細介紹了。
可見，使用一個DO從頭用到尾（從資料庫到前端頁面）並不是一種好的設計。
如何正確的使用DO、DTO、VO
對於上面的例子，我們可以將他設計成以下類。由於模型並不複雜，這裡只需要再引入VO就可以了。
UserDO已經和資料庫欄位一一對應了，這裡不需要修改。
public class UserDO {
private Integer id; //唯一主鍵
private Date createdTime; //建立時間
private Date updatedTime; //最後更新時間
private String name; //姓名
private Integer age; //年齡
private String gender; //性別
private String address; //住址
private String password; //密碼
private String nickName; //暱稱
private Date birthday; //生日
private String education; //學歷
private String politicalStatus; //政治面貌,1表示群眾,2表示團員,3表示黨員,4表示其他,100表示未知
private Integer companyId; //公司的ID
private Integer status; //資料狀態,1表示可用,0表示不可用
//setter and getter
}引入UserVO，用於封裝傳遞到前端需要展示的欄位。
public class UserVO {
private Integer id; //唯一主鍵
private String name; //姓名
private Integer age; //年齡
private String gender; //性別
private String address; //住址
private String nickName; //暱稱
private Date birthday; //生日
private String education; //學歷
private String politicalStatus; //政治面貌，群眾、團員、黨員等
private Company company; //公司
//setter and getter
}UserVO中只包含了展示所需要的欄位，並不需要展示的欄位在這裡不需要包含。
在引入了這個類之後，我們就可在進行資料庫查詢的時候使用UserDO，然後再需要傳遞到前端的時候把DO轉換成VO。
總結
看到這裡，你可能已經發現，UserDO和UserVO中包含了大量的相同欄位。難道真的有必要再單獨設計個VO嘛？我可以明確告訴你的是，當你的系統越來越大，表中的欄位越來越多的時候，使用DO\DTO\VO等概念進行分層處理是絕對有好處的。至於如何進行有效的在不同的實體類間進行轉換是我接下來要介紹的。
優雅的將DO轉換成VO
Dozer 是一個物件轉換工具。
Dozer可以在JavaBean到JavaBean之間進行遞迴資料複製,並且這些JavaBean可以是不同的複雜的型別。
所有的mapping，Dozer將會很直接的將名稱相同的fields進行復制，如果field名不同，或者有特別的對應要求，則可以在xml中進行定義。
前面我們介紹的DO\DTO\VO不就是JavaBean嘛。正好可以使用Dozer進行轉換呀。
除了使用Dozer，當然你還由其他選擇：
典型的解決方案就是手動拷貝，弊端很明顯，程式碼中充斥大量Set 和Get方法，真正的業務被埋藏值與值的拷貝之中。
另一種方案就是使用BeanUtil，但BeanUtil不夠很好的靈活性，又時候還不得不手動拷貝。Dozer可以靈活的對物件進行轉換，且使用簡單。
Dozer 支援的轉換型別
Primitive 基本資料型別 , 後面帶 Wrapper 是包裝類 Complex Type 是複雜型別
• Primitive to Primitive Wrapper
• Primitive to Custom Wrapper
• Primitive Wrapper to Primitive Wrapper
• Primitive to Primitive
• Complex Type to Complex Type
• String to Primitive
• String to Primitive Wrapper
• String to Complex Type if the Complex Type contains a String constructor
• String 到複雜型別 , 如果複雜型別包含一個 String 型別的構造器
• String to Map
• Collection to Collection
• Collection to Array
• Map to Complex Type
• Map to Custom Map Type
• Enum to Enum
• Each of these can be mapped to one another: java.util.Date, java.sql.Date, java.sql.Time, java.sql.Timestamp, java.util.Calendar, java.util.GregorianCalendar
• String to any of the supported Date/Calendar Objects.
• Objects containing a toString() method that produces a long representing time in (ms) to any supported Date/Calendar object. 在普通Java專案中使用Dozer
在pom.xml中增加依賴
<dependency>
<groupId>net.sf.dozer</groupId>
<artifactId>dozer</artifactId>
<version>5.5.1</version>
</dependency>使用Dozer進行類轉換
public class Main {
public static void main(String[] args) {
DozerBeanMapper mapper = new DozerBeanMapper();
UserDO userDO = new UserDO();
userDO.setName("hollis");
userDO.setAddress("hz");
userDO.setAge(25);
userDO.setCompanyId(1);
userDO.setBirthday(new Date());
userDO.setGender("male");
userDO.setEducation("1");
userDO.setNickName("hollis");
userDO.setPoliticalStatus("3");
UserVO userVO = (UserVO) mapper.map(userDO, UserVO.class);
System.out.println(userVO);
}
}特殊的欄位轉換
在使用mapper進行轉換前，設定一個或多個mapping檔案
List myMappingFiles = new ArrayList();
myMappingFiles.add("dozer-mapping.xml");
mapper.setMappingFiles(myMappingFiles); 配置dozer-mapping.xml檔案
資料型別不一致，或者名稱不相同或者有級聯關係等情況下，可以通過檔案dozer-mapping.xml來進行定製Bean的轉換
<?xml version="1.0" encoding="UTF-8"?>
<mappings xmlns="http://dozer.sourceforge.net" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://dozer.sourceforge.net
http://dozer.sourceforge.net/schema/beanmapping.xsd">
<mapping>
<class-a>com.hollis.lab.UserDO</class-a>
<class-b>com.hollis.lab.UserVO</class-b>
</mapping>
</mappings>在JavaWeb專案中使用Dozer
在pom.xml中增加依賴
<dependency>
<groupId>net.sf.dozer</groupId>
<artifactId>dozer</artifactId>
<version>5.5.1</version>
</dependency>使用Spring整合dozer
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<bean id="baseMapper" class="org.dozer.spring.DozerBeanMapperFactoryBean">
<property name="mappingFiles">
<list>
<value>classpath:mapping/dozer-mapping.xml</value>
</list>
</property>
</bean>
</beans> 使用baseMapper進行Bean的轉換
@Autowired
private Mapper baseMapper;
private UserVO doToVo(UserDO userDO){
if(userDO == null) return null;
UserVO vo = baseMapper.map(userDO, UserVO.getClass());
if(userDO.getCompanyId != null) getCompany(vo);
return vo;
}通過以上的程式碼加配置，我們就實現了從DO轉換到VO的部分操作，之所以說是部分操作，是因為我們在dozer-mapping.xml並沒有做多餘的配置，只是使用dozer將DO中和VO中共有的屬性轉換了過來。對於其他的型別不同或者名稱不同等的轉換可以參考官網例子通過設定dozer-mapping.xml檔案來實現。
上面還有一個getCompany()沒有實現。這個方法其實就是通過companyId查詢出company實體然後在賦值給UserVO中的company屬性。
在使用了dozer之後，我們可以把UserDO中的部分屬性賦值到UserVO中，其實，轉化的過程是通過呼叫UserDO中的getter方法和UserVO中的setter方法來實現的。讀者可以做個實驗，對於UserVO中的部分屬性不寫Setter方法看看還能不能把屬性值轉換過來，博主已經測試過了，是不能的。