首先是從概念上來說
POJO，全稱Plain Ordinary Java Object，我理解為極其單純的Java物件
一般只有屬性欄位，無參構造以及get和set方法，也是指那些沒有從任何類繼承、也沒有實現任何介面，更沒有被其它框架侵入的java物件。
因此它特別靈活可擴充套件，可以實現讓一個模型貫穿多個層，簡單來說可以理解成不包含業務邏輯的單純用來儲存資料的 java類
entity
實體bean，一般是用於ORM物件關係對映，一個實體對映成一張表，一般無業務邏輯程式碼。
負責將資料庫中的表記錄對映為記憶體中的Entity物件，事實上，建立一個EntityBean物件相當於建立一條記錄，刪除一個EntityBean物件會同時從資料庫中刪除對應記錄，修改一個Entity Bean時，容器會自動將Entity Bean的狀態和資料庫同步。

關於區分POJO和entity，查了一些資料也沒發現有特別大的差別，功能上來說差別不大，只能從含義上大致區分一下。不過現在大都是用entity來作為一個表對映的類。

DTO（Data Transfer Object）資料傳輸物件

這個概念來源於J2EE的設計模式，原來的目的是為了EJB的分散式應用提供粗粒度的資料實體，以減少分散式呼叫的次數，從而提高分散式呼叫的效能和降低網路負載，現在多用於展示層與服務層之間的資料傳輸物件。

那麼問題來了，為什麼要用DTO呢？為什麼不能直接用實體模型呢
首先是效率問題：
因為原始的請求方式帶來的缺點有很多，多次請求耗費一定的網路資源，減慢效率。如果一次性返回整個實體類，還可能造成資料庫表結構的洩漏。
DTO層可以隔離Domain Model，讓DoMain Model的改動不會直接影響到UI；保持Domain Model的安全,並且不暴露業務邏輯。

Domain Model可以理解為 為POJO增加業務邏輯的方法（比如單據稽核、轉帳……）之後變成。

舉個例子
比如我們一張表有100個欄位，那麼對應的PO就有100個屬性。
但是我們介面上只要顯示10個欄位，
客戶端用service來獲取資料，沒有必要把整個PO物件傳遞到客戶端，
這時我們就可以用只有這10個屬性的DTO來傳遞結果到客戶端，這樣也不會暴露服務端表結構.

PO是指持久物件（persistant object持久物件）。
為POJO增加了持久化的方法（Insert、Update、Delete……）之後，POJO就變成了PO。

VO是指值物件或者View物件（Value Object、View Object）。
為POJO增加了資料繫結功能之後，POJO就變成了View Object，即UI Model。

還有就是關於持久化就是把你的資料寫到檔案或資料庫儲存下來的過程
程式碼舉例
POJO到PO

 @GetMapping(value="/addgames")
    public void addGames() {
        Games game = new Games();//初始化一個POJO，或者entity
       //set值作為是持久化處理的過程
        game.setId(12);
        game.setName("龍珠超宇宙");
        game.setType("熱血格鬥");
        game.setSeries("七龍珠");
        game.setPrice(10.0);
        //呼叫saveOne方法進行持久化，儲存進資料庫，變為PO，代表一條表資料
        gamesMapper.saveOne(game);
    }

POJO到VO

@RequestMapping(value = "/thymeleaf")
    public  String ThymeleaPage(Model model){
        Hero hero = heromapper.getAHeros();//呼叫DAO層的方法拿到一個POJO
        model.addAttribute("heroInfo", hero);//繫結到heroInfo，變為一個VO
        return "index";
    }

新建DTO，只選擇需要傳輸到前端的欄位資料

@Data
public class GamesDTO
{
        private Integer id;

        private String name;

        private String type;

        private String image;

}

同樣的可以去增加資料繫結。