Concepts of several O entity classes in Java projects

Often come into contact with the concept of Vo,do, DTO, thisarticle from the domain modeling of the Entity division and the actual application of the project in two angles, the concept of these several simple analysis.

The main conclusion is that in the project application,VO corresponds to the data (form) that needs to be displayed on the page,do corresponds to the data (data table) stored in the database, and thedto corresponds to the data that needs to be passed in addition to the two.

First, the entity class

The definition of entity class in Baidu Encyclopedia is as follows:

The primary responsibility of an entity class is to store and manage information inside the system, and it can have behavior, even complex behavior, that must be closely related to the entity object it represents.

Based on the above definition, we can see that the entity class has two aspects, storing the data and performing the operations related to the data itself. These two aspects correspond to the implementation, the simplest entity class is the Pojo class, contains the property and property corresponding to the set and get method, the entity class common method also has to output own data the tostring method.

Ii. entity classes in the domain model

Entities in the domain model

There are four types of classes: Vo, dto, do,Po, various entity classes are used for interactions between different business tiers, and transformations between entity classes are implemented within the hierarchy.

A business hierarchy is: The View layer (view+action), the service layer (services), the Persistence layer (dao)

The corresponding inter-tier entities are passed as

We do not strictly follow this transfer relationship in the project, but this and business-level correlation is helpful in understanding the role of each entity class. (We don't have the reason to contact the Po, I understand that the PO is encapsulated for ORM )

The following is the original text of the information, based on this drawing:

Concept:

Vo ( View Object ): The View object, used for the presentation layer, that encapsulates all the data for a specified page (or component).

DTO ( Data Transfer Object ): Data Transfer object, this concept originates from the design pattern of the Java EE, the original purpose is to provide the coarse granularity data entity for the distributed application of EJB, to reduce the number of distributed calls, thus improve the distributed call Performance and reduce network load, but here I refer to the data transfer object between the presentation layer and the service layer.

Do ( domain Object ): domain objects are tangible or intangible business entities that are abstracted from the real world.

PO ( Persistent Object ): a persisted object that forms a one by one mapping relationship to the data structure of the persistence layer (usually the relational database), and if the persistence layer is a relational database, then each field (or several) in the data table corresponds to one (or several) attributes of the PO.

Model:

The following is a sequence diagram that establishes a simple model to describe the location of the above objects in a three-tier architecture application

The user makes a request (possibly filling out a form), and the data of the form is matched to VO in the presentation layer .

The display layer converts VO to the DTO required by the service layer correspondence method and transmits it to the service layer.

The service layer first constructs (or rebuilds) a do based on the data of the DTO , invoking the Do business method to complete the specific business.

The service layer converts do to the PO that corresponds to the persistence layer (you can use the ORM tool or not), calls the persistence method of the persistent layer, passes the PO to it, and completes the persistence operation.

L for a reverse operation, such as reading data, is also converted and passed in a similar way, slightly.

Iii. entity classes in the project

The common entity classes in the project are vo,do, and DTO, and the naming conventions often end with corresponding strings, such as *vo.java. But DTOs do not always follow this rule and are usually related to his use, such as writing *query.java, which means that a query condition is stored. The business hierarchy of the entity classes in the project is not so strict, for example, we can assemble a do on the view layer, or we can send a vo out of the persistence layer, so the partitioning method associated with the business hierarchy seems redundant. The abstraction from the project code is thatvo corresponds to the data that needs to be displayed on the page,do corresponds to the data stored in the database, and thedto corresponds to data that needs to be passed in addition to the two.

Concepts of several O entity classes in Java projects