JavaBean之個人理解

JavaBean分爲兩種，其也能夠稱爲POJO(Plain Ordinary Java Object)：

  一、VO(View Object)：值對象，主要用於封裝頁面上表單的數據；

  二、PO(Persisent Object)：持久化對象，主要用於封裝數據庫表中的數據，其取名通常爲表名；

 

問題：

在SSH2開發中的數據前進過程，VO、POJO、PO之間的轉換有什麼好處？

若是這些O之間相互轉換，我認爲會增長如下問題：

一、屬性拷貝增長了大量的工做量；

二、過多的對象轉換帶來性能上損失，而對象的內容幾乎相同；

三、容易形成混淆，既然都是內容相同的對象，爲什麼不能使用一個，POJO就能代替大部分O，各個O之間相互轉換的好處是什麼？

 

回答：

VO(View Object)：值對象，用於封裝界面數據。POJO：相似於JavaBean的java類。

PO(Persisent Object)：持久化對象，也就是數據庫表對應的類，主要是爲了分離層與層之間的耦合性。

首先應該遵照的原則：

一個界面最好對應一個VO類，而不該該向界面傳不少對象或List，用於顯示或獲取界面中的參數。一個數據庫表對應一個PO類，而其餘地方須要額外用到的類就是POJO了。

舉例：我須要在界面上顯示全部的角色，點擊角色選擇角色下的全部用戶，那麼這個界面的數據類，也就是VO，應該包含三個元素：全部的角色，選擇的角色，所選角色的用戶，轉換爲VO對象就是：List<角色>、角色、List<用戶>，這些數據涉及到兩個PO類，也就是角色和用戶，咱們能夠在後臺根據業務需求876913451進行獲取。那爲何會出現VO類，我直接把須要的全部數據，好比List<角色>、角色、List<用戶>經過request傳到界面上不就好了？這樣從實現功能上說沒有問題，可是假如把你寫的程序給你別人看，別人乍一看，他知道你向界面傳了多少對象？難道他必需要從頭至尾看一遍你的業務邏輯代碼嗎？想一想你在業務代碼中這兒向request中傳huiny30347121一個對象，那兒又傳一個對象，這樣很不現實，不利於二次開發(而大多數軟件都是須要進行二次開發的)，也不利於由於客戶需求的變化改代碼，並且最主要的是，這樣不能體現面向對象思想，對於一系列數據，咱們應該封裝成一個類，這是基本的封裝思想。

至於屬性的拷貝：相對於你後期須要改代碼時的痛苦來講，這樣寫更清晰，更好，不是嗎？

對象轉換上的性能損失：相對於B/S系統來講，制約用戶訪問速度的關鍵因素應該是網速吧，也就是客戶端和服務器端的數據交換。但你可能會說，那爲何數據庫常常提到性能問題呢，由於數據庫有時須要處理幾十萬條數據，假如你的sql語句寫的不精練的話，用戶點一下按鈕，可能多等待幾十秒。可是對象轉換不可能帶來太多的影響，對吧！最後，假如你怕對象轉換帶來性能損失，那你就寫一個對象得了，全部的代碼都在裏面寫，這樣好嗎？因此，咱們277413318必需要在性能、便於開發、便於維護之間找到一個平衡點。