Shulou(Shulou.com)06/03 Report--

This article mainly shows you the "domain-driven model VO, DTO, DO, PO what is the difference", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn the "domain-driven model VO, DTO, DO, PO what is the difference between" this article.

Entity classes in the domain model

The entity classes in the domain model are divided into four models: VO, DTO, DO and PO. Various entity classes are used for the interaction between different business levels, and will realize the transformation between entity classes within the hierarchy.

The business layer is composed of view layer (VIEW+ACTION), service layer (SERVICE) and persistence layer (DAO). The delivery of entities between the corresponding layers is as follows:

VO (View Object) View object

Used in the presentation layer, its function is to encapsulate all the data of a given page (or component).

DTO (Data Transfer Object) data transfer object

This concept comes from the design pattern of J2EE, the original purpose is to provide coarse-grained data entities for EJB distributed applications, in order to reduce the number of distributed calls, so as to improve the performance of distributed calls and reduce the network load, but here, it is mainly used for data transfer objects between the presentation layer and the service layer.

For example, if a table has 100 fields, the corresponding DTO has 100 attributes (in most cases, the data in the DTO comes from multiple tables). But the view layer only needs to display 10 fields, and there is no need to pass the entire PO object to client, so we can use DTO with only these 10 attributes to transfer data to client, so that the table structure on the server side is not exposed. After arriving at the client, if you use this object to display the interface, then its identity will be changed to VO.

DO (Domain Object) domain object

It is a tangible or intangible business entity abstracted from the real world.

PO (Persistent Object): persisting object

It forms an one-to-one mapping with the data structure of the persistence layer (usually a relational database). If the persistence layer is a relational database, then each field in the data table corresponds to an attribute of PO.

For the understanding of the above concepts, we may not be able to form an abstract thinking. We use a timing diagram to build a model to describe the position of the above objects in the application of three-tier architecture:

The user submits the request (perhaps by filling out the form), and the data on the form is matched as VO at the presentation layer.

The service layer converts the VO into the DTO required by the corresponding method of the service layer and transmits it to the service layer.

First of all, the service layer constructs a DO (or reconstruction) based on the data of DTO, and calls the business method of DO to complete the specific business.

The service layer converts the DO into the PO corresponding to the persistence layer (usually using the ORM tool), calls the persistence method of the persistence layer, passes the PO to it, and completes the persistence operation.

For a reverse operation, such as reading data, it is converted and passed in a similar way.

Comparison between VO and DTO

The difference between VO and DTO

Here we may ask: since DTO is the object that passes data between the presentation layer and the service layer, why do you need a VO?

Yes, for most application scenarios, the attribute values of DTO and VO are basically the same, and they are usually POJO, so there is no need to bother. But don't forget that this is the thinking of the implementation layer, for the design level, there should still be VO and DTO conceptually, so there is an essential difference between the two. DTO represents the data that needs to be received and returned by the service layer, while VO represents the data that needs to be displayed in the presentation layer.

It might be easier to understand with an example:

For example, the Service layer has a getUser method that returns a system user, one of which is gender (gender). For the Service layer, it is only semantically defined: 1-male, 2-female, 0-unspecified, while for the presentation layer, it may need to use "handsome brother" for male, "beautiful woman" for female, and "secret" for unspecified.

Speaking of which, you may also retort that you can just go back to "handsome guys and beauties" at the service level. This is not a problem for most applications, but imagine that if the requirements allow customers to customize the style, and different clients have different requirements for the presentation layer, then the problem arises. Furthermore, back to the analysis at the design level, from the principle of single responsibility, the service layer is only responsible for the business and has nothing to do with the specific form of expression, so the DTO it returns should not be coupled with the form of expression.

The theory belongs to the theory, after all, it is still the thinking at the analysis and design level, and is it necessary to do so at the specific implementation level? An one-size-fits-all approach often outweighs the gain, so let's analyze how to make the right choice in the application.

Application of VO and DTO

The above is just a simple example of the conceptual difference between VO and DTO. Here we analyze how to make the right choice in the application.

In the following scenarios, we can consider merging VO and DTO into one (note: at the implementation level):

When the requirements are very clear and stable, and the client is clear that there is only one, there is no need to distinguish between VO and DTO. At this time, VO can retire and use a DTO. Why is VO retired instead of DTO? Back at the design level, the responsibilities of the service layer should still not be coupled with the presentation layer, so for the previous example, you can easily understand that DTO still can't use "handsome guys and beauties" for "gender". This conversion should rely on the script of the page (such as JavaScript) or other mechanisms (JSTL, EL, CSS).

Even if the client can be customized or there are multiple different clients, VO can be retired if the client can implement the transformation using some technology (scripting or other mechanism).

The following scenarios need to give priority to the coexistence of VO and DTO:

For some technical reason, for example, when a framework (such as Flex) provides automatic conversion of POJO to some Field in UI, you can consider defining VO at the implementation level. This trade-off depends entirely on the comparison between the improvement in development and maintenance efficiency brought about by the automatic conversion capability of the framework and the decline in development and maintenance efficiency caused by designing one more VO.

If there is a "large view" on the page, and all the data that makes up this large view needs to call multiple services and return multiple DTO to assemble (of course, this can also be replaced by providing DTO that returns one large view at once in the service layer, but whether it is appropriate to provide such anti-corrosion at the service layer needs to be weighed at the design level).

Comparison between DTO and DO

The difference between DTO and DO

First of all, there is the difference in concept. DTO is the data transfer object between the presentation layer and the service layer (can be regarded as the protocol between the two), while DO is the abstraction of various business roles in the real world, which leads to the difference in data between the two.

For example, UserInfo and User, for a getUser method, essentially should never return a user's password, so UserInfo has at least one less password data than User. In domain-driven design, DO is not a simple POJO, it has domain business logic.

Application of DTO and DO

Reverse the problem from the above: since the UserInfo returned by the getUser method should not contain password, the attribute definition password should not exist, but what if there is also a createUser embalming and the incoming UserInfo needs to contain the user's password?

At the design level, the DTO passed from the presentation layer to the service layer is conceptually different from the DTO returned by the service layer to the presentation layer, but at the implementation level, we rarely do this (define two UserInfo or more), because it is not very wise to do so, and we can design a fully compatible DTO when the service layer receives data. The properties that should not be set by the display layer (for example, the trace of the order should be determined by its unit price, quantity, discount, etc.) are ignored by the service layer regardless of whether the display layer is set or not, and when the service layer returns data, the corresponding properties are not set for data that should not be returned (such as user password).

For DO, there is one more thing to note: why not return DO directly in the service layer? This saves the coding and conversion of DTO for the following reasons:

The essential difference between the two may lead to non-one-to-one correspondence between the two, one DTO may correspond to multiple DO, and vice versa, or even there is a many-to-many relationship between the two.

DO has some data that should not be made known to the presentation layer

DO has business methods. If DO is passed directly to the presentation layer, the code of the presentation layer can bypass the service layer and directly call operations that it should not access. This problem is especially prominent for the mechanism based on AOP intercepting the service layer for access control, and calling DO business methods in the presentation layer will also make things difficult to control because of the problem of things.

For some ORM frameworks (such as Hibernate), "delayed loading" technology is usually used. If DO is exposed directly to the presentation layer, for most cases, the presentation layer is not within the scope of things (Open session in view is not a praiseworthy design in most cases). If it tries to get an unloaded associated object with Session turned off, a runtime exception will occur (for Hibernate, it is LazyInitliaztionException).

From the design level, the presentation layer depends on the service layer, and the service layer depends on the domain layer. If the DO is exposed, the presentation layer will directly rely on the domain layer. Although it is still one-way dependent, this cross-layer dependency will lead to unnecessary coupling.

For DTO, it is also important to note that DTO should be a "flat two-dimensional object" for example:

If User is associated with several other entities (such as Address, Account, Region, etc.), does the UserInfo returned by getUser () need to return all the DTO of its associated object? If so, it will inevitably lead to a great increase in the amount of data transmission. for distributed applications, this design is more unacceptable because it involves data transmission, serialization and deserialization over the network.

If getUser needs to return an AccountId, AccountName, RegionId, RegionName in addition to the basic information of User, then define these properties in UserInfo and "squash" a "three-dimensional" object tree into a "flat two-dimensional object".

Comparison between DO and PO

The difference between DO and PO

In most cases, DO and PO correspond one to one. PO is a POJO with only get/set methods, but some scenarios still reflect the essential conceptual differences between the two:

In some scenarios, DO does not need explicit persistence. For example, the commodity discount policy designed using the policy pattern will derive the discount policy interface and different discount policy implementation classes. These discount policy implementation classes can be regarded as DO, but they only reside in the static memory pool and do not need to be persisted to the persistence layer. Therefore, there is no corresponding PO for this kind of DO.

By the same token, in some scenarios, PO does not have a corresponding DO. For example, there is a many-to-many relationship between teacher Teacher and student Student. In a relational database, this relationship needs to be represented as an intermediate table, that is, there should be a PO of TeacherAndStudentPO, but this PO does not have any practical significance in the business domain, and it cannot correspond to any DO at all.

Here, I'd like to make it clear that not all many-to-many relationships have no business meaning, which is related to specific business scenarios. For example, if the relationship between two PO affects specific business, and there are many types of this relationship, then this many-to-many relationship should also be represented as a DO. For example, there is a many-to-many relationship between "role" and "resource", and this relationship will obviously show as a DO-- "permission".

In some cases, a PO may correspond to multiple DO for some persistence strategy or performance considerations, and vice versa. For example, customer Customer has its contact information Contacts, here are two one-to-one relationship DO, but may be out of performance considerations (extreme cases, right as an example), in order to reduce database connection query operations, merge Customer and Contacts DO data into one data table. Conversely, if a book Book, there is an attribute is the cover cover, but this attribute is a picture of binary data, and some query operations do not want to load cover, thus reducing disk IO overhead, while assuming that the ORM framework does not support attribute-level delayed loading, then you need to consider independent cover into a data table, thus forming a DO corresponding to multiple PO situation. Some attribute values of PO do not make any sense to DO. These attribute values may be used to solve the data that exists in some persistence strategies. For example, in order to implement an "optimistic lock", PO has a property of version, this version is of no business significance to DO, and it should not exist in DO. Similarly, there may be attributes in DO that do not need to be persisted.

Application of DO and PO

Because the ORM framework is very powerful and popular, and JavaEE has also launched the JPA specification, now the business application development basically does not need to distinguish between DO and PO,PO can be hidden in the DO through JPA,Hibernate Annotations/hbm. Even so, there are some problems that we must pay attention to:

For attributes that do not need to be persisted in DO, you need to explicitly declare them through ORM, such as: in JPA, you can declare them with @ Transient.

For attributes in PO that exist for a certain persistence strategy, such as version, because DO and PO are merged, they must be declared in DO, but because this attribute has no business significance to DO, it needs to be hidden from the outside. The most common practice is to privatize the get/set method of the attribute, or even not provide the get/set method. However, for Hibernate, this requires special attention. Because when Hibernate reads data from the database to DO, it first uses the reflection mechanism to call the empty parameter constructor of DO to construct the DO instance, and then uses the JavaBean specification to reflect the set method to set the value for each property. If the set method is not explicitly declared, or the set method is set to private, Hibernate will not be able to initialize DO, resulting in a runtime exception. It is feasible to set the set method of the property to protected.

Hibernate provides good support for scenarios where a DO corresponds to multiple PO, or a PO corresponds to multiple DO, as well as delayed loading at attribute level. Please refer to the relevant materials of Hibnate.

These are all the contents of this article entitled "what's the difference between domain-driven models VO, DTO, DO, and PO?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.