VO、DAO、BO 等對象

在了解這里 po、vo、dao、之前先介紹下 MVC 開發模式

• M層負責與數據庫打交道；
• C層負責業務邏輯的編寫；
• V層負責給用戶展示（針對于前后端不分離的項目，不分離項目那種編寫模版的方式，理解V的概念更直觀）。

而VO，BO，PO，DO，DTO呢，就是穿梭在這M、V、C層之間的實體傳輸對象

阿里巴巴規范手冊關于VO，BO，PO，DO，DTO這些的描述

分層領域模型規約：

• DO(Data Object)：此對象與數據庫表結構一一對應，通過 DAO 層向上傳輸數據源對象。
• DTO(Data Transfer Object)：數據傳輸對象，Service 或 Manager 向外傳輸的對象。
• BO(Business Object)：業務對象，由 Service 層輸出的封裝業務邏輯的對象。
• AO(ApplicationObject)：應用對象，在Web層與Service層之間抽象的復用對象模型，極為貼近展示層，復用度不高。
• VO(View Object)：顯示層對象，通常是 Web 向模板渲染引擎層傳輸的對象。
• Query：數據查詢對象，各層接收上層的查詢請求。注意超過 2 個參數的查詢封裝，禁止使用 Map 類來傳輸。

領域模型命名規約：

• 數據對象：xxxDO，xxx即為數據表名
• 數據傳輸對象：xxxDTO，xxx為業務領域相關的名稱。
• 展示對象：xxxVO，xxx一般為網頁名稱。
• POJO是DO/DTO/BO/VO的統稱，禁止命名成xxxPOJO。

Pojo 和 javabean

POJO是 Plain Old Java Object 的簡寫，大概意思就是“淳樸的Java對象”。這個詞是國外一家外包公司的員工創造的。哪些類是POJO類還是有說法的，需要同時滿足以下幾個條件：

1. 不實現任何接口的類。

2. 不繼承任何其它類的類。

3. 不使用任何外部注解的類。

這種類其實就是切斷了和外界聯系的Java類，下面這個類肯定不是：

@Data
public class Dog {private String name;private Integer age;
}

這個類才是

public class Dog {private String name;private Integer age;
}

Java Bean也經常出現在各種技術文獻中，也不是隨便什么類都能叫做Java Bean的，它需要有以下定義：

● 有無參數構造。

● 所有的屬性必須是私有屬性（private）。

● 所有的屬性必須有公共的（public）的Getter和Setter。

● 它必須是可以被序列化的，也就是實現 java.io.Serializable接口。

按照這個定義，POJO類如果想成為Java Bean，需要改造成下面的形式

import java.io.Serializable;public class Dog implements Serializable {private static final long serialVersionUID = 6723564465081191620L;private String name;private Integer age;public String getName() {return name;}public void setName(String name) {this.name = name;}public Integer getAge() {return age;}public void setAge(Integer age) {this.age = age;}
}

其實在Spring 中對于 Bean的要求就低多了，只要這個類（接口）被注入了Spring IoC，那么這個類（接口）都可以被稱作一個Spring Bean。所以一個POJO總是孤孤單單的，它不可能成為一個Java Bean或者Spring Bean，但是Java Bean可以同時是一個Spring Bean；Spring Bean也可以是一個Java Bean

項目中真的有必要定義VO，BO，PO，DO，DTO嗎？

還是要理性看待這個問題，要看項目“目的地”是什么。

如果項目比較小，是一個簡單的MVC項目，又是單兵作戰，不建議使用VO，BO，PO，DO，DTO，直接用POJO負責各個層來傳輸就好，因為這種項目的“目的地”是快速完成。

而更多的時候，是持續迭代的團隊協作項目，這個時候就建議用VO，BO，PO，DO，DTO，而且團隊內要達成共識，形成一個標準規范。

不管用哪種方式，只要團隊內定義好一種適應的協同規范就行。沒有一個絕對好與絕對壞的方式方法，團隊規范的盡頭能提升項目的可擴展性、可維護性與可閱讀性，從而降低bug率。