先了解一些抽象對象概念
BIZ和service的區別項目前期 或者小項目沒什么太大區別
但是項目大了以后 區別就很大了
項目開發到后期的話 你一個項目內包含有其他的小項目 比如 后台 erp 商城 等等 都用的是同一個數據庫
這個時候 就不能使用一個service/biz 全部解決了 有些業務是通用的 有一些業務可能只有erp有 其他模塊沒有 也有可能同一個業務 在細微上有一些差別 如果全部都放進一個業務層中的話 這個業務層就會非常的臃腫
這個時候就需要拆分 一個基礎業務層 一個應用層業務層
基礎業務層只是針對該對象的CURD操作 應用業務層就是一個復雜的功能模塊或流程
舉個例子 service作基礎業務層 biz作為應用層業務層
比如我現在要在商城中 做一個下單功能 牽涉到商品，庫存，活動等等 那么我把這個東西放哪呢？ 訂單service層? 如果放到這里 訂單service層中就會引入商品，庫存，活動的service或dao 如果還有其他功能 那么這個模塊牽涉到的功能就越來越多 所以並不合適 不光商城中牽涉到訂單service 后台也可能會用到 erp也可能會用到 那么這時候就需要做個一個應用層
可以去了解一下 DDD 領域驅動設計
VO
value object：值對象
通常用於業務層之間的數據傳遞，由new創建，由GC回收。
PO
persistant object：持久層對象
對應數據庫中表的字段。
VO和PO，都是屬性加上屬性的get和set方法；表面看沒什么不同，但代表的含義是完全不同的。
DTO
data transfer object：數據傳輸對象。
表里面有十幾個字段：id,name,gender(M/F),age,conmpanyId(如001)...
頁面需要展示四個字段：name,gender(男/女),age,conmpanyName(如今日頭條股份有限公司)。
DTO由此產生，一是能提高數據傳輸的速度（減少了傳輸字段），二能隱藏后端表結構。
BO
business object：業務對象
BO把業務邏輯封裝為一個對象。
我理解是PO的組合，比如投保人是一個PO，被保險人是一個PO，險種信息是一個PO等等，他們組合起來是第一張保單的BO。
POJO
plain ordinary java object：簡單無規則java對象
純的傳統意義的java對象，最基本的Java Bean只有屬性加上屬性的get和set方法。
可以轉化為PO、DTO、VO；比如POJO在傳輸過程中就是DTO。
DAO
data access object：數據訪問對象
主要用來封裝對數據的訪問，注意，是對數據的訪問，不是對數據庫的訪問。
（1）dao轉dto
因為dao中查詢的數據是數據庫中的所有字段，但是返回給前端的字段有一些不能返回給他們，比如密碼這些私密信息。這時候就需要封裝dto類定義需要返回的字段。dao轉dto，使用transfer根據（待補）
（2）封裝自定義map。比如一個map中需要put進來sso對象，userinfo等對個對象，這時候需要封裝自己的map。
@Data
@Bulider
public class UserMap(){
Sso sso;
UserInfo userinfo;
}
使用：
UserMap userMap = new UserMap；
userMap.put(返回對象）；