PO
A Persistant Object (PO) can be viewed as a Java Object that maps to tables in a database. The simplest PO is a single record in a table in the database. Multiple records can be a collection of pos. The PO should not contain any operations on the database. The advantage is that one record can be treated as an object, which can be easily converted to other objects. PO consists of a set of attributes and their GET and set methods. PO is created when new data is added to the database and deleted when data is deleted from the database. The PO can only survive in one database connection and is destroyed upon disconnection. PO is stateful, and each attribute represents its current state, which is an object representation of physical data. Using it, we can decouple our programs from physical data and simplify the conversion between object data and physical data. The PO attribute is a one-to-one mapping to the fields of the database table. PO objects need to implement serialization interfaces.
VO
Value Object Value object. It is commonly used for data transfer between business layers and, like PO, contains only data. But it should be an abstract business object, which may or may not correspond to a table, depending on the needs of the business. Personally feel the same as dtos (Data transfer objects), passed over the Web. VO consists of a set of attributes and their GET and set methods. VO is created with the new keyword and is collected by GC. VO is a value object, or business object, that lives in the business layer and is used by business logic to provide a place for microdata to live. VO attributes vary according to the current business, that is, each attribute corresponds to the name of the data required by the current business logic.
DAO
Data Access Object is a standard J2EE design pattern for Sun. This object is used to access the database. Often used in conjunction with a PO, daOs contain operations on various databases. Through its method, combined with PO to carry out relevant operations on the database. Sandwiched between business logic and database resources. Cooperate with VO to provide CRUD operation of database.
BO
BO (Business Object) is a Java Object that encapsulates Business logic. DAO is invoked to perform Business operations in combination with PO and VO. This object can contain one or more other objects. A resume, for example, has education, work experience, connections, etc. We can put educational experience for one PO, work experience for one PO, relationships for one PO. Create a BO object corresponding to the resume to process the resume, and each BO contains these pos. This allows us to process the business logic against the BO. There are three main concepts about BO:
- Contains only properties of the business object;
- Only business methods are included;
- It’s both.
In practical use, it is not important to think which concept is correct, the key is to suit the needs of their own projects in practical application
POJO
Pojos (Plain Ordinary Java Objects) are pure traditional Java objects. That is, in some Object Relation Mapping tools, the Persisent Object that can maintain database table records is a pure Java Object that conforms to the Java Bean specification without adding other attributes and methods, that is, the most basic Java Bean. Just property fields and setter and getter methods!
- A POJO is persisted as a PO;
- You pass it directly, DTO in the process;
- The direct counterpart to the presentation layer is VO.
DTO
Data Transfer Object (DTO) is mainly used for remote invocation where a large number of Transfer objects are required. For example, if we have a table with 100 fields, the corresponding PO will have 100 attributes. Instead of passing the entire PO object to the client, we can use dtos with only these 10 attributes to pass the result to the client without exposing the server table structure. When it arrives at the client, if this object is used for the interface display, its status changes to VO. A DTO is a simple container for a set of aggregated data that needs to be transported across process or network boundaries. It should not contain business logic and limit its behavior to activities such as internal conformance checks and basic validation. Be careful not to rely on any new classes as a result of implementing these methods. When designing data transfer objects, you have two main options: use general collections; Or create custom objects using explicit getters and setters.
application
Different types of objects are used for different purposes in architectural design, and the following hierarchical architecture represents the purpose of each POJO. POJO objects are defined in the hierarchy to ensure that each layer encapsulates its own services and effectively controls the dissemination of information.
The example analysis
Take an example to explore the use of POJOs. Suppose we have an interview system with a database of interview questions, served through the Web and AN API. The following design may be done:
- Data table: Interview questions in the table include number, question, option, answer, creation time and modification time;
- PO: includes question, option, answer, creation time, modification time;
- VO: Question, choice, answer, previous question URL, next question URL;
- DTO: number, question, option, answer, previous question number, next question number;
- DAO: database add, delete, change and check method;
- BO: basic service operations.
As you can see, with POJO partitioning, we have a well-designed architecture where changes to data objects at each level can be controlled within a limited range.
References:
- zhuanlan.zhihu.com/p/42288383