POJO
簡單的JAVA對象（Plain ordinary Java Objects）實際就是普通JavaBeans,使用POJO名稱是為了避免和EJB混淆起來, 而且簡稱比較直接。
其中有一些屬性及其getter setter方法的類,有時可以作為value object或dto(Data Transform Object)來使用。
當然,如果你有一個簡單的運算屬性也是可以的,但不允許有業務方法,也不能攜帶有connection之類的方法。
PO
PO(persistant object) 持久對象，可以看成是與數據庫中的表相映射的java對象。一張表對映一個PO。
最簡單的PO就是對應數據庫中某個表中的一條記錄，多個記錄可以用PO的集合。PO中應該不包含任何對數據庫的操作。
DAO
DAO (data access object) 數據訪問對象，此對象用于訪問數據庫。
通常和PO結合使用，DAO中包含了各種數據庫的操作方法。通過它的方法,結合PO對數據庫進行相關的操作。
DTO
DTO (Data Transfer Object)
數據傳輸對象,主要用于遠程調用等需要大量傳輸對象的地方。比如我們一張表有100個字段，那么對應的PO就有100個屬性,但是我們界面上只要顯示10個字段，客戶端用WEB service來獲取數據，沒有必要把整個PO對象傳遞到客戶端，這時我們就可以用只有這10個屬性的DTO來傳遞結果到客戶端，這樣也不會暴露服務端表結構。到達客戶端以后，如果用這個對象來對應界面顯示，那此時它的身份就轉為VO。
VO
VO(value object) 值對象，通常用于業務層之間的數據傳遞，和PO一樣也是僅僅包含數據而已。
但應是抽象出的業務對象,可以和表對應,也可以不,這根據業務的需要。個人覺得同DTO(數據傳輸對象),在web上傳遞。
BO
BO：全稱是business object:業務對象，主要作用是把業務邏輯封裝為一個對象。這個對象可以包括一個或多個其它的對象。
比如一個簡歷，有教育經歷、工作經歷、社會關系等等。我們可以把教育經歷對應一個PO，工作經歷對應一個PO，社會關系對應一個PO。
建立一個對應簡歷的BO對象處理簡歷，每個BO包含這些PO。這樣處理業務邏輯時，我們就可以針對BO去處理。
biz
biz是Business的縮寫，是業務邏輯層，一般意義上和service層差不多。項目前期或者小項目沒什么太大區別，但是項目大了以后區別就很大了。
項目開發到后期的話，一個項目內包含有其他的小項目，比如：后臺、erp、商城等等，都用的是同一個數據庫。這個時候，就不能使用一個service/biz 全部解決了。有些業務是通用的，有一些業務可能只有erp有，其他模塊沒有，也有可能同一個業務，在細微上有一些差別，如果全部都放進一個業務層中的話，這個業務層就會非常的臃腫。這個時候就需要拆分，一個基礎業務層，一個應用層業務層，基礎業務層只是針對該對象的CURD操作
應用業務層就是一個復雜的功能模塊或流程。
這時可以考慮service作基礎業務層，biz作為應用層業務層。service是比較底層的api，biz是應用層的api。可以結合DDD領域驅動設計理解。
充血模型與貧血模型
貧血模型最早廣泛應用是源自于EJB2，最強盛時期則是由Spring創造，把“行為”（也稱為邏輯、過程）和“狀態”（可理解為數據，對應到語言就是對象成員變量）分離到不同的對象之中，那個只有狀態的對象就是所謂的“貧血對象”（常稱為VO——Value Object），而那個只有行為的對象就是我們常見的N層結構中的Logic/Service/Manager層（對應到EJB2中的Stateless Session Bean）。
充血模型其實很簡單，就是面向對象設計的本質：“一個對象是擁有狀態和行為的”，比如說一個人，他眼睛什么樣鼻子什么樣這就是狀態，人可以去打游戲或是寫程序，這就是行為。
總結
貧血模型, 將數據與db操作分離, 分個好幾層, 如entity/dao/service等。
充血模型, 數據與db操作綁在一次, 一般只涉及到一兩層。
充血模型層數少,代碼少, 改動少, 簡單, 優雅，一般復雜的系統可以考慮用充血模型，簡單系統用貧血模型也并沒有什么影響。
如若轉載，請注明出處：開源字節 https://sourcebyte.cn/article/229.html
