Do vo and pojo need to be separated in actual projects?

I still cannot understand vo and pojo. First, Let's explain what I Think vo and pojo are.
Assume that a project uses STRUTS + hibernate
There are two classes in the project.
CN. VO. userlist
This class uses VO to transmit data in Bo and to pages.
CN. Hib. pojo. userlist
This is mainly used to transmit data with the database.

I want to ask many people to separate pojo from VO. I don't understand this.
However, almost all the attributes in the table correspond to the fields of a database table.
Why don't I directly use pojo to transmit values?
If they are separated, write one more class.
And switch every time
For example

CN. hib. pojo. userlist user = (CN. hib. pojo. userlist) session. get (CN. hib. pojo. userlist. class, 1); // here get pojo CN. VO. userlist vuser = new CN. VO. userlist (); // create a Vo object instance beanutils. copyproperties (vuser, user); // use beanutils for conversion

In this way, I think the code is cumbersome and I cannot feel the benefits of doing so.
Is it difficult to transmit data using only one pojo?

Thank you for talking about how you did it in actual development.

Certificate ----------------------------------------------------------------------------------------------------------------------------------------

Differences between vo and Po:
1. Vo is created with the New Keyword and collected by GC.
Po is created when new data is added to the database and deleted when the data in the database is deleted.
And it can only survive in one database connection. When the connection is disconnected, it will be destroyed.
2. Vo is a value object. To be precise, Vo is a business object that is alive at the business layer. It is a business object.
Logic is used. The purpose of survival is to provide a place for data to survive.
Po is stateful, and each attribute represents its current status. It is the object of physical data.
. Using it can decouple our program from physical data and simplify it
Conversion between object data and physical data.
3. VO attributes vary according to the current business, that is, each of its
All attributes correspond to the names of the data required by the current business logic.
Po attributes correspond to the fields in the database table one by one.
4. Vo is an independent Java object.
Po is an object that is incorporated into the entity map by hibernate. It represents
The Hibernate object corresponding to a record in the database. The po changes during transaction commit
Returns to the actual database.

The main reasons for replacing VO with Po are:
The parameter and return type of the method at the business layer cannot be pojo, because when pojo is in the persistent state, it will synchronously update the database, which brings a certain risk, that is, the data is modified when the user is not aware. Therefore, pojo cannot be operated in the controller, instead of VO. You can use VO to avoid exceptions when the session is closed.