004.Java in PO, DO, DTO, VO, BO, POJO, DAO, TO concepts

004.Java in PO, DO, DTO, VO, BO, POJO, DAO, TO concepts

 

relation chart

1. Concept

1. PO (persistant object) persistent object

   The concept appears when O / R mapping, if there is no O / R mapping, no such concept exists.

   Generally corresponding to the data model (  database  ), the processing section itself, there are business logic.

   It can be seen as the Java objects in the database appearances map .

   The simplest  PO  is a corresponding database in a record in a table, the plurality of recording may be set PO.

   PO should not contain any database operation.

2. DO (Domain Object) domain objects

   Is from the real world, tangible or intangible business entity abstracted.

3. DTO (Data Transfer Object) data transfer object

   This concept comes J2EE design patterns, the original purpose of a distributed application data entities EJB coarse-grained, in order to reduce the number of calls distributed, thereby improving the performance of distributed call and reduce network load, but here, I refers to data transfer objects between the presentation layer and the service layer .

4. VO (Value Object) value of the object

   Typically for data transfer between the service layers, and PO it is as it only contains data. But it should be an abstract of a business object, and the table may correspond to, or may not, based on business needs it. Created with the new keyword, recovered by the GC.

5. BO (Business Object) Business Objects

   From a business point of view the model, see UML element domain object in the domain model.

   Java objects encapsulate business logic, by calling the DAO methods, combined PO, VO business operations.

   Business Object: Business Objects

   The main role is to encapsulate business logic for an object . This object can comprise one or more other objects. For example, a curriculum vitae, educational experience, work experience, social relations, and so on. We can put educational experience corresponds to a PO, work experience corresponds to a PO, social relations corresponding to a PO. Establishing a resume process corresponding to the object BO resume, each of these comprising BO PO. In this way the business logic processing, we will be able to deal with for BO.

6. POJO (Plain Ordinary Java Object) simple Java objects without rules

   Traditional Java objects. That is, in some Object / Relation Mapping tool, able to do maintenance of the database table records Persisent Object is entirely consistent with a pure Java objects Java Bean specification, no increase in other properties and methods. My understanding is that the most basic Java Bean, only attribute fields and getter and setter methods! .

   POJO is DO / DTO / BO / VO collectively.

7. DAO (data access object) data access object

   Sun is a standard J2EE design patterns, this model has interfaces that DAO, which is responsible for operating the persistence layer. It provides an interface for the business layer. This object is used to access the database. PO usually used in combination, DAO contains a method for operating the various databases. By its methods, PO binding to the database related operations. Caught in the middle of the business logic and database resources. With VO, provide CRUD operations on the database.

8. TO (Transfer Object), data transfer object

   Objects between different TIE (relationship) the application transmitted

2. The difference between the application and

The difference between (1) VO and the DTO

Since DTO is subject to transfer data between the presentation layer and the service layer, why do you need a VO it?

Correct! For most of the scenarios, the property values of DTO and VO are basically the same , but they usually are POJO, so no need to bother, but do not forget that this is achieved the level of thinking for the design level , the concept of or should exist on VO and DTO, because both are essentially different, DTO represents the service layer needs to receive the data and return data, and data presentation layer represents the VO to be displayed.

Use an example to illustrate might be easier to understand:

For example: a method getUser Service layer system returns a user, a property which is gender (Sex), for the Service layer, it is defined only semantically: 1- male, 2 female, 0-unspecified, As for the presentation layer, it may need to use "male" for male, with "beauty" for women, with a "secret" for unspecified. Here, you might also argue, direct returns "hotties" in the service layer is not on line yet? For most applications, this is not a problem, but imagine if demand allows customers to customize styles, and different styles for "Sex" is not the same performance, or the service at the same time for multiple clients using (different portal ), and different requirements for client presentation layer are different, then the problem came. Again, back to the design level of analysis, from a single responsibility principle point of view, the service layer is responsible only for the business, irrespective of the particular form of expression, therefore, it returns the DTO, should not be coupled with the emergence of forms.
Theoretical return theory, which in the end is the level of analysis and design thinking, do we have to do so at the level it achieved? One size fits all approach is often not worth the candle, I'll analyze the following applications how to make the right choice.

(2) VO applications and DTO

The above are just used a simple example to illustrate the difference between VO and DTO in concept, this section will tell you how to make the right choice in the application.

In the following scene before we can consider VO and DTO two-in-one (note: to achieve levels):

When demand is very clear and stable, and the client is very clear there is only one time, there is no need to distinguish VO and DTO area, VO can retire at this time, you can use a DTO, VO Why is retired and not DTO? Back to the design level, the responsibility remains Service layer should not be coupled with the View layer, therefore, for the previous example, you can easily understand, DTO for "sex", it still can not use the "hotties", the conversion should depend on page scripts (such as JavaScript) or other mechanisms (JSTL, EL, CSS)
even if the client can be customized, or the presence of a number of different clients, to achieve the conversion if the client is able to use certain technology (scripts or other mechanisms), Also allows VO retire

The following scenarios need to give priority VO, DTO co-exist:

For some technical reasons, such as a framework (such as Flex) provides automatic converts the POJO for the UI in some Field, consider the definition of a VO at implementation level, this trade-off depends entirely on the ability to use automatic conversion framework to bring development and maintenance efficiencies and design one more than the decline between the VO do things that bring development and maintenance efficiency.

If the page appears a "big view", which consists of all of the data in this large view of the need to call multiple services, multiple DTO return to the assembly (of course, it can also provide a one-time return a large view of DTO through the service layer in place, but in the service layer to provide such a method is appropriate, we need to balance the design level).

The difference between (3) DTO and the DO

The first is the conceptual distinction, DTO is data transfer objects between the View layer and Service layer (may be considered to be an agreement between the two), while DO is an abstraction of the real world a variety of business roles , which leads to two by differences in the data, e.g. UserInfo and user, getUser for a method, it should never returns the user's password in nature, so a password UserInfo data at least one less than the user. In the field of the design of the drive, DO is not a simple POJO, having a business logic field.

(4) DTO and DO application

From an example, the careful reader may find the question: If the method returns UserInfo getUser should not contain password, then it should not exist in this attribute defines the password, but if there is a method createUser the same time, incoming UserInfo need to include the user's password, how do? In the design level, View layer transferred to the Service Layer Service layer DTO and returned to the DTO View layer is different in concept, but in the implementation level, we usually rarely do (define two UserInfo, or even more) , because it does not seem very wise, we can design a fully compatible DTO, when the service layer receives the data, property should not be set by the View layer (such as the total price of the order should its price, quantity discount decisions, etc.), regardless of whether the layer is disposed View, Service layer are not and will be ignored, and in the layer returns Service data, (e.g., a user password) should not be returned, the corresponding attribute is not set.

For DO, the more thing: Why not Service layer directly back to DO it? Such encoding can be omitted and conversion work DTO for the following reasons:

• The difference in nature may cause not correspond to each other, a DTO may correspond to multiple DO, and vice versa, even the two-many relationship exists.
• Some should not be allowed to know the data layer View DO DO have a business with a method, if the DO passed directly to the View layer, the code can bypass the View layer Service layer directly invoke operations it should not have access, for layer-based AOP intercept Service mechanisms for access control, this problem is particularly acute, and calls business methods in the View layer DO also because the problem affairs, so that the transaction is difficult to control.
• For some ORM frame (e.g., Hibernate), the often use "lazy loading" technique, if directly exposed to the DO View layer, for the most part, not within the scope of a transaction layer of View (Open session in view in most design is not a case worthy of praise), if it attempts to get the case closed Session object associated unloaded, an exception (for Hibernate, it is LazyInitiliaztionException runtime) will appear.
• From the design perspective, the, the View layer depends on the Service layer, Service layer depends on the domain layer, if exposed to the DO, it will lead directly dependent on the View layer dao layer, although this is still a one-way dependence, but this cross-layer dependence can lead to unnecessary coupling

For DTO, there is also little to be explained, is the DTO should be a " flat two-dimensional object ", focusing on understanding

To give an example to illustrate: If it will be associated with a number of User other entities (such as Address, Account, Region, etc.), then getUser () returned UserInfo, whether it is necessary to DTO objects that are associated together to return? If so, inevitably lead to increase the amount of data transmission, for distributed applications, since the transmission data over the network directed, serialization and deserialization, this design is more unacceptable. If getUser addition to the basic information of the User return, but also a need to return AccountId, AccountName, RegionId, RegionName, then, to make these attributes define the UserInfo, to a "three-dimensional" object tree "collapsed" into a "flat the two-dimensional object, "the author of the project is currently involved in a distributed system that willy-nilly, all associated objects are converted to an object DTO object tree and return the same structure, resulting in very slow performance .

(5) the difference in DO and PO

DO and PO in most cases is one to one, PO containing only POJO get / set methods, but some scenes still reflect the difference between the two concepts exist in nature:

DO in some scenarios do not require explicit persistence, for example, by discounts on merchandise strategy pattern design policy, the policy will be derived discount Discount different interfaces and implementation classes, these classes can be regarded as a discount policy implementation DO, they only reside in static memory, need not persisted to the persistence, so that such is not the corresponding PO DO exist.

By the same token, in some scenarios, PO there is no corresponding DO, such as the presence of many-teacher Teacher and student Student, In a relational database, this relationship need to show a middle table, it corresponds to a TeacherAndStudentPO the PO, but this PO do not have any real significance in the field of business, it can not be completely on any DO correspondence.

It must declare that not all many relationships have no business meaning, which with about specific business scenarios, such as: the relationship between the two PO affect specific business, and there are many types of this relationship, then this many relationships should also be expressed as a DO, Another example: many relationship exists between "role" and "resources", and this relationship is clearly manifested as a DO-- "privilege."

In some cases, for some persistent policy or performance considerations, PO may correspond to a plurality of DO, and vice versa. Such as customer Customer Contacts have their contact information, here are two DO-one relationship, but perhaps due to performance considerations (in extreme cases, the right for example), in order to reduce connection query the database, the Customer and two Contacts DO data incorporated into a data table. Conversely, if a Book Book, there is a cover cover property, but the property is a picture of binary data, but some queries do not want to cover operating load together, thereby reducing the overhead of disk IO, and assuming ORM framework does not support attribute-level lazy loading, then we need to consider the cover to a separate data table to go, thus forming a DO to deal with a case of the PO.

Some attribute values ​​for DO PO does not make any sense, these property values ​​may be in order to solve some of the data persistence strategy exists, in order to achieve "optimistic locking", PO exist such as a version of the property, this version is for DO there is no business sense, it should not exist in the DO. Similarly, DO also may not require the presence of persistent attributes.

(6) DO and PO applications

Since the function ORM framework is very powerful and popular, but also introduced a JavaEE JPA specifications, current business application development, basically you do not need to distinguish between DO and PO, PO entirely by JPA, Hibernate Annotations / HBM hidden in the DO. Nevertheless, we must also pay attention to some problems:

For DO unnecessary persistent attributes need to explicitly declare the ORM, such as: In JPA may be utilized @Transient statement.

For the PO in order to some persistence strategy exists properties, such as version, due DO, PO merger must be declared in the DO, but because of this property of DO is not any business sense, you need to let the Foreign property hidden the most common practice is to get the property / set methods of privatization, it does not even provide get / set methods, but for Hibernate, this requires special attention, due to Hibernate reads data from the database to convert DO, is the use of examples reflection mechanism to call DO DO null argument constructor function, and then using the reflected JavaBean specification set methods for each property value is set, if not set explicitly declared method, or a method to set the private, will lead to unable to initialize Hibernate DO, so abnormal and feasible approach is to set the property is protected method set to run the event.

For a corresponding number of PO DO, or a corresponding number of PO DO scene, as well as property-level lazy loading, Hibernate provides good support, please refer to the Hibernate relevant information.