sequence

Now that we’ve touched it, everyone must have some questions about DO, BO, VO, DTO. What the hell is this? How does it work? Why do you do that? Here are the answers.

What is?

First of all, they are all POJos, which are our custom JAVA classes. The difference is the hierarchy and the properties

The properties of this Object correspond to the database table fields one by one, such as DyinggqDO

This Object corresponds to the Service layer, which is commonly used in the development of XxxServerImpl objects, it will have some property differences with DO, usually we will give DO to BO conversion method, Or use the Mapper kit. Such as DyinggqBO

VO (View Object) Display layer Object This Object usually corresponds to the Controller layer, which is the JSON serialized Object that we will eventually return to the front end. Such as DyinggqVO

Data Transfer Object (DTO). The term DTO is a bit confusing at first glance. In this way, we can define DTO as objects that an RPC interface requests to receive, objects that provide an RPC interface to transmit, or objects that are parsed by an external API called JSON within our JAVA. Such as DyinggqDTO

Why is that?

1. Why these distinctions?

Just as we layered the package structure, distinguishing poJOs helps keep the code clean, functional, and uncluttered, and in large projects and complex scenarios this distinction is really needed, where the requirements are.

2. Why DO and BO?

In complex business scenarios, poJOs used by our Service layer cannot be satisfied by DO, that is, the corresponding class of a single table. In many cases, in the Service layer, BO may combine several tables for aggregation definition, and its attributes are processed by aggregation, such as lists or computed fields. All the distinctions between BO and DO are necessary. Of course there is nothing wrong with using DO directly in simple scenarios, and it is the right code to define it only when it is really needed.

3. Why VO?

Very simple thinking, the front end does not need all the data in the background, corresponding in the interface, we only need to return the fields they need to be able to avoid the transfer of garbage data and unnecessary data leakage, we supply as little as possible to the front end, let the front end itself in his one acre three points to play well.

3. Why DTO?

With the above explanation, it should be obvious why this is so. The object that the external request comes back to is defined as a DTO. A comfortable batch

The last

Finally really need to distinguish between use, know how to use, know when to use, hope this article is helpful to you

I am aDying strandedI am always looking forward to meeting you. Whether you expect it or not, tides come and go, I’m just here…