A brief description of common object types in Java (DO, BO, DTO, VO, AO, PO, etc.)


During the learning process of the Alibaba JAVA Development Manual, I found that the manual mentioned many concepts such as DO, BO, DTO, VO, PO, etc., so I found relevant content on the Internet for learning. This article basically refers to the following:
Common in Java Brief description of object types (DO, BO, DTO, VO, AO, PO)

1. Concept and understanding

These concepts are used to type description object ;
Because java is object-oriented languages, the program is the world of "interaction between the various objects ";
will interact with the project there are multiple levels , each level being owned (Watch) The contents of are all different ;

1.PO (Persistant Object) Persistent Object

Used to represent the java object mapped into a record in the database. PO is only used to represent data, without any data manipulation. Usually follow the Java Bean specification and have getter/setter methods.

It can be understood that a PO is a record in the database; it can understand the original data that a transaction depends on; the advantage is that a record can be processed as an object, and it can be easily converted into other objects

2.BO (Business Object) business object

Encapsulated objects, complex objects, which may contain multiple classes The
main function is to encapsulate business logic as an object. This object can include one or more other objects.

Used to represent a business object. BO includes business logic, often encapsulates calls to DAO, RPC, etc., and can convert between PO and VO/DTO. BO is usually located in the business layer, which is different from the service layer that directly provides services to the outside world: BO provides the basic business operations of the basic business unit, and is designed to be an object called by the service layer business process. A business process may need to call multiple BOs. To be done.

For example, a resume, with educational experience, work experience, social relations and so on.
We can map education experience to a PO, work experience to a PO, and social relationships to a PO.
Create a BO object corresponding to the resume to process the resume, and each BO contains these POs.
When dealing with business logic in this way, we can deal with BO.

3.VO (Value Object) performance object

Front-end interface display; value object value object; ViewObject presentation layer object; mainly corresponding to the data object displayed on the interface. For a WEB page, or an interface of SWT or SWING, a VO object corresponds to the value of the entire interface; for Android, it is a data element in an activity or view.

Used to represent a java object that interacts with the front end. Some friends may have questions, is it possible to use PO to transfer data here? In fact, the VO here only contains the data that the front-end needs to display. For the data that the front-end does not need, such as the time of data creation and modification, for the purpose of reducing the size of the transmitted data and protecting the database structure from leakage, It should not be reflected in VO. Usually follow the Java Bean specification and have getter/setter methods.

4.DTO (Data Transfer Object) data transfer object

Transmission when the front-end is called; it can also be understood as transmission when the "upper layer" is called; for
example, if we have 100 fields in a table, then the corresponding PO has 100 attributes. But as long as 10 fields are displayed on our interface, the client uses the WEB service to get the data. There is no need to pass the entire PO object to the client. At this time, we can use the DTO with only these 10 attributes to pass the result to the client. This will not expose the server-side table structure. After arriving at the client, if this object is used to correspond to the interface display, then its identity will be changed to VO.

Used to represent a data transfer object. DTO is usually used for data transmission between different services or different layers of services. The concept of DTO and VO is similar, and usually the fields are basically the same. However, there are some differences between DTO and VO. This difference is mainly due to the design concept. For example, the DTO used by API services may be different from VO. Usually comply with the Java Bean specification and have getter/setter methods

5.DAO (Data access object) data access object

This is the most familiar to everyone, and the biggest difference from the above Os, there is basically no possibility and necessity of mutual conversion. It is mainly used to encapsulate the access to the database. Through it, POJO can be persisted into PO, and VO and DTO can be assembled with PO;

Used to represent a data access object. Use DAO to access the database, including operations such as insert, update, delete, and query, and use it with PO. DAO is generally in the persistence layer, completely encapsulating database operations, and the method of external exposure makes the upper-level application need not pay attention to any information related to the database.

6.POJO(Plain ordinary java object) Simple java object

After a POJO is persisted, it is PO; it is directly used to transfer, and it is DTO in the process of transfer; directly used to correspond to the presentation layer is VO.

Two, example

For example:
things: statistics of quarterly performance in the R&D department (tentatively based on the engineer’s entry, of course, most of them are not)

Process: CTO releases statistical performance request (with requirements: each person’s corresponding performance level) -> each group (or sub-department) responsible person releases statistical performance request (each corresponding performance level, and the performance is divided into 3 Aspect) -> Each development engineer counts his own performance (in all aspects of himself);
you can see from the example: each responsible person has different requirements;
for the CTO, what he needs to know is the performance level of the employees used in the quarter; here you can Think VO: employee name, performance level;
development engineer: I need to list all aspects of my performance this quarter: employee name, performance level, performance content and grade of A, performance content and grade of B, and performance content of C And grade, D aspect performance content and grade, E aspect performance content and grade, F aspect performance content and grade, E aspect performance content and grade; here can be regarded as PO: employee name, performance level, A aspect performance content, A Aspect level...E aspect performance content, E aspect level;
then the development engineer transmits the employee's name, performance level, A aspect performance content and level, B aspect performance content and level, and C aspect performance content and level content to the team leader; The object passed here
is the person in charge of the DTO team: After obtaining the data from the development engineer, it is evaluated, and then the employee's name, performance level, and reason are obtained; the evaluation here can be understood as BO;

Guess you like

Origin blog.csdn.net/ambitionLlll/article/details/111626971