With the deepening of the programming industrialization level, various programming models emerge in endlessly (such as MVC, MVP, etc.), and along with these programming models, a large number of new concepts flock in. What is the difference between VO, BO, PO, DO, and DTO? Kind of like, these new concepts have always been in the clouds. Although there are many articles on the Internet to distinguish these concepts, it seems that they are basically reprinted from several identical articles, and these articles themselves are also unclear. , some contradict each other, and some articles use these concepts in the simplified system, which makes people more and more confused
What caused this chaotic state, I won’t go into details, and it feels difficult to find out why. Therefore, it is
enough for us to base ourselves on these concepts themselves and achieve a consistent understanding of the concepts. This is also the main purpose of this article. Purpose
In view of the fact that there are too many explanations of technical terms on the Internet, I will not repeat the terms once I search a lot, and to be honest, the terms are too abstract and not conducive to understanding. Explain in vernacular (human language), so that everyone can understand
Not much nonsense, let’s take a look at the picture first. After reading
the picture, most people probably already have an intuitive feeling.
Facing this picture, let’s start with
DTO (Data Transfer Object) data transfer object,
which is a link between the past and the future. Transmission usually refers to the transmission between the front and back ends.
DTO is a special object. It has two forms of existence:
at the back end, its existence form is a java object, which is the stuff defined in the controller, usually in The back end does not need to care about how to convert from json to java objects. This is done by some mature frameworks for you. For example, the spring framework is
on the front end, and its existence form is usually an object in js (it can also be simply understood as json ), that is, the data body requested through ajax,
which is why it is drawn across two layers
There may be a problem here. Now that microservices are prevalent, can the transfer object called between services be called DTO?
My understanding is that depending on the situation,
an implicit meaning of DTO itself is to be able to fully express the output of a business module.
If the service and the service are relatively independent, then it can be called a DTO.
If the service and the service are not independent, each It is not a complete business module, and the disassembly may only be due to computational complexity or performance issues, then this cannot be called a DTO, it can only be a BO
VO (Value Object) The value object
VO is the data for display, no matter the display method is a webpage, a client, or an APP, as long as this thing is visible to people, it is called VO. The main
form of VO is in js The object (can also be simply understood as json)
The difference between VO and DTO
There are two main differences.
One is that the fields are different, and VO will delete some fields as needed;
the other is that the values are different, and VO will explain the value of DTO according to the needs of the display business.
Give a simple example
DTO could be like this
{
"gender":"男",
"age":35
}
For business one, only gender is needed, and because it is an ancient chat room, men cannot be directly displayed, so after business explanation, the VO of business one is
{
"gender":"公子"
}
For business 2, only the age is needed, and the exact age is not required, so after business explanation, the VO of business 2 is
{
"age":"30~39"
}
PO (Persistent Object)
PO is easier to understand.
Simply put, PO is a record in the database. The data structure of a PO corresponds to the structure of the table in the database. A record in the table is a PO object. Usually, except get and set
in PO, There is no other way
. For PO, the number is relatively fixed and must not exceed the number of database tables. It is
equivalent to Entity, and the two concepts are consistent.
BO (Business Object) business object
BO is the combination of PO.
For example, PO is a transaction record, and BO is a collection of all transaction records of a person. For a more
complex example, PO1 is transaction record, PO2 is login record, and PO3 is Commodity browsing record, PO4 is the record of adding shopping cart, PO5 is the search record, BO is the behavior object of personal website. BO is
a business object, and a class of business will correspond to a BO. There is no limit on the number, and BO will have many business operations. That is to say, in addition to the get and set methods, BO has many methods for calculating its own data.
Why is BO also drawn across two layers? The reason is that many persistence layer frameworks now provide the function of data combination, so BO may be formed by assembling PO at the business layer, or it may be directly generated by the framework at the database access layer in order to pursue queries
. Efficiency. It is very common for the framework to skip PO and directly generate BO. PO is only used for addition, deletion, and modification.
The difference between BO and DTO
The difference between the two is mainly the deletion of fields
. BO is internal. In order to perform business calculations, auxiliary data is needed, or a business has multiple external interfaces. BO may contain many interfaces that are not needed externally. Therefore, DTO needs to be based on BO, as long as it needs the data, and then provide it externally
in this relationship, usually there will be no change in data content, and the content change is either completed during BO’s internal business calculation, or explained Completed by VO
OK, these relationships are basically cleared up here
Wait, what is DO
? Isn't there a DO in the title?
The above concepts have basically covered all the processes, DO is only the same as one of the concepts,
but which concept is the same?
Now there are mainly two versions.
One is the definition of
DO (Data Object) in Alibaba’s development manual, which is equivalent to the above PO,
and the other is DO (Domain Object) in DDD (Domain-Driven Design),
which is equivalent to BO above
Finally, let's talk about the practical application.
These concepts are very complete. Do we have to follow this when we use them?
Of course not, the complexity of the system is different from the system, and the level of collaboration is different. There is no need for dogmatism.
I will give some practical suggestions on which concepts to use
and which ones to save. Entity, no matter what you have to have
2, some tool systems and some systems with less complex business DTO can be merged with BO into one, when the business expands, pay attention to splitting 3,
VO can be optimized first , if the display business is not complicated, you don’t need it at all. Use DTO
4 directly. This is also the most important one. The concept is for people. When multiple people collaborate, you must ensure that everyone’s concepts are consistent. who you work with
Welcome to pay attention to the official account, communicate together and make progress together