Several objects of Java (Po,vo,dao,bo,pojo) explained

Vo is a mapping to a table in a database, and a table corresponds to a VO
DAO is to use VO to access the real table, the operation of the database is done in DAO
Bo is the business layer that does the logical processing

VO, PO, BO, QO, DAO, POJO

The O/R Mapping is an abbreviation for the Object Relational Mapping.

The popular point is that the object is bound to the relational database, and the object is used to represent the relational data. In the O/R

In the world of Mapping, there are two basic and important things to understand, namely VO, PO.

VO, the Value object,

PO, persistent objects (persistent object), which are composed of the get and set methods of a set of properties and properties. Structurally, they are nothing different. But it is completely different from its meaning and nature.
1. VO is created with the New keyword and collected by the GC.
The PO is created when new data is added to the database, and the data in the database is deleted. And it can only survive in a database connection, and the disconnection is destroyed.
2. VO is a value object, the precise point is that it is a business object, is living in the business layer, is used by business logic, it is the purpose of survival is to provide a place for the data to survive.
The PO is stateful, and each property represents its current state. It is the object representation of the physical data. Using it, we can decouple our programs from physical data and simplify the transformation between the object data and the physical data.
3. VO's properties are different depending on the current business, that is, each of its properties corresponds to the name of the data needed for the current business logic.
The properties of the PO correspond to the field one by one of the database table.
The PO object needs to implement the serialization interface.
-------------------------------------------------

Java's (Po,vo,to,bo,dao,pojo) explanation
PO (Persistant object) Persistent object
The concept that occurs at the O/R mapping, without the O/R mapping, does not exist. Usually the corresponding data model (database), itself also has some business logic processing. Can be seen as a Java object mapped to a table in the database. The simplest PO is a record in a table in the corresponding database, and multiple records can be used with a collection of PO. The PO should not contain any operations on the database.
VO (Value object) value objects
Typically used for data transfer between business tiers, as is the case with PO, which contains only data. But it should be abstracted out of business objects that can correspond to tables, or not, depending on the needs of the business. Individuals feel the same DTO (data transfer object) that is passed on the web.
to (Transfer object), data transfer object
Objects that are transferred between different tie (relationships) in the application
BO (business object) service object
From the business model perspective, see the domain objects in the UML component Domain model. A Java object that encapsulates the business logic, by invoking the DAO method and combining PO,VO for business operations.
Business object: Operational objects
The main role is to encapsulate the business logic as an object. This object can include one or more other objects.
such as a resume, education experience, work experience, social relations and so on.
We can have an education experience corresponding to a PO, work experience corresponding to a PO, social relations corresponding to a PO.
Create a CV-based Bo object to process resumes, each Bo containing these PO.
When we handle business logic like this, we can deal with BO.
QO: Querying objects
POJO (Plain ordinary Java object) simple, rule-free Java objects
Java objects that are purely traditional in meaning. Which means in some object/relation
Mapping tool to maintain the persisent of database table records
object is a pure Java object that conforms to the Java Bean specification and does not add other properties and methods. My understanding is the most basic Java Bean, only attribute fields and setter and getter Method!.
DAO (data Access object) Access objects
is a sun's standard Java EE design pattern, which has an interface that is DAO, which has negative persistence layer operations. Provides interfaces for the business layer. This object is used to access the database. Usually used in conjunction with PO, DAO contains various methods of operation of the database. Through its method, combine the PO to carry on the related operation to the database. Sandwiched between business logic and database resources. With VO,
Provide CRUD operations for the database ...

Dto:
Data Transfer Object Data transfer objects
It is mainly used for remote calls, etc. where large quantities of objects need to be transferred.
For example, if we have 100 fields in a table, then the corresponding PO has 100 attributes.
But we just show 10 fields on the interface,
The client uses the WEB service to get the data, and there is no need to pass the entire PO object to the client.
At this point we can pass the result to the client with a DTO with only these 10 attributes, so that the service-side table structure is not exposed. After reaching the client, if the object is used to display the corresponding interface, then its identity will be converted to VO

DAO: Data Access Object--also DAO mode

DTO: Data Transfer Object-also DTO mode

Example:

VO: The View object, which is 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 is derived from the design pattern of the Java EE, the original purpose is to provide a coarse-grained data entity for the distributed application of EJB, to reduce the number of distributed calls, thus improve the performance of distributed calls and reduce the 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 with 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.

Vo differs from dto  
       You may have a question (in the project I'm involved in, Many programmers also have the same doubts: why do we need a VO if the DTO is the object that passes data between the presentation layer and the service layer? Right! For most scenarios, dto and VO attribute values are basically consistent, and they are usually pojo, so there is no need to superfluous, but do not forget that this is the implementation level of thinking, for the design level, there should be the concept of VO and DTOs, because the two have an essential difference, A DTO represents the data that the service layer needs to receive and the data returned, and VO represents the data that the presentation layer needs to display.  
       Use an example to illustrate that it may be easier to understand: for example, the service layer has a GetUser method that returns a system user with a property of gender (gender), For the service layer, it is only semantically defined: 1-male, 2-female, 0-unspecified, and for the presentation layer, it may need to use "handsome" on behalf of men, with "beautiful" for women, with "secret" representative unspecified. Speaking of which, perhaps you will also refute, in the service layer directly back to "handsome" is not OK? This is not a problem for most applications, but imagine that if the requirements allow customers to customize the style, and the different styles do not behave differently for "gender", or if the service is used by multiple clients (different portals), and different clients have differing requirements for the performance layer, then the problem comes. Furthermore, back to the design level, from a single principle of responsibility, the service layer is only responsible for the business, independent of the specific manifestation, therefore, the DTO that it returns should not appear coupled with the form of expression.  
       theory, this is the analysis of the design level of thinking, whether the implementation level must do so? One-size-fits-all approach tends to outweigh the gains, and I'll immediately analyze how to make the right choices in the app.

The application of VO and DTO
The above only uses a simple example to illustrate the conceptual difference between VO and dto, and this section will show you how to make the right choice in your application.
In the following scenario, we can consider the VO and the Dto two to one (note: is the implementation level):
When the requirements are very clear and stable, and the client is very clear only one time, there is no need to distinguish between VO and dto, when VO can retire, with a dto can, why Vo retired rather than DTOs? Back to the design level, the responsibility of the service layer should still not be coupled with the presentation layer, so, for the previous example, you can easily understand that DTOs for "gender", still can't use "handsome", this conversion should rely on the page script (such as JavaScript) or other mechanisms (JSTL, EL, CSS)
Even if the client can be customized, or there are many different clients, if the client can use a technology (script or other mechanism) to achieve the conversion, the same can let VO retire

The following scenarios need to prioritize VO and dto coexistence:
The reverse scenario of the above scenario
For some technical reasons, such as when a framework (such as Flex) provides automatic conversion of Pojo to some field in the UI, you can consider defining VO at the implementation level, This tradeoff is entirely dependent on the comparison between the development and maintenance efficiencies brought about by the use of the framework's automatic conversion capability and the increased efficiency of the development and maintainability of the design more than what VO does.
If a page appears with a "large view," and all the data that makes up the large view needs to call multiple services and return multiple DTOs to assemble (of course, this can also be replaced by a dto that returns a large view at the service layer, but it is appropriate to provide a method at the service layer, Needs to be weighed at the design level).

The difference between a dto and do
The first is the conceptual difference between a DTO is a data transfer object between the presentation layer and the service layer (which can be considered an agreement between the two), and do is an abstraction of the various business roles in the real world, which leads to differences in data, such as userinfo and user (for DTO and do naming conventions, See the author's previous blog post), for a GetUser method, essentially it should never return a user's password, so userinfo at least one password less data than the user. In domain-driven design, as the first series of articles says, do is not a simple pojo, it has domain business logic.

The application of DTO and do
From the example in the previous section, the attentive reader may find the problem: Since the userinfo returned by the GetUser method should not contain password, there should be no password this attribute definition, but if there is a CreateUser method at the same time, What if the incoming userinfo needs to contain the user's password? At the design level, the DTO that the presentation layer passes to the service layer is conceptually different from the DTOs that the service layer returns to the presentation layer, but at the implementation level, we typically rarely do this (define two userinfo, or more), because it is not necessarily 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 presentation layer (such as the total price of the order should be determined by its unit price, quantity, discount, etc.), regardless of whether the presentation layer is set up, the service layer is ignored, and when the service layer returns data, the data should not be returned (such as user password),
For do, there is one more thing to note: Why not just return to do in the service layer? This eliminates the code and conversion work for DTOs for the following reasons:
The difference between the two is inherently different, which may lead to one by one correspondence, a DTO may correspond to multiple do, and vice versa, and even the two have many-to-many relationships.
Do has some data that should not be known to the presentation layer
Do has a business method, if you pass the do to the presentation layer, the Code of the presentation layer can bypass the service layer directly call it should not access the operation, for the mechanism of access control based on the AOP interception service layer, this problem is particularly prominent, and the presentation layer calls do business method also because of the problem of the transaction, Make transactions difficult to control.
For some ORM frameworks, such as Hibernate, the "lazy loading" technique is often used, and if do is exposed directly to the presentation layer, for the most part, the presentation layer is not within the scope of the transaction (Open session in view is not a worthy design in most cases), If it tries to get an associated object that is not loaded when the session is closed, a run-time exception occurs (for Hibernate, lazyinitiliaztionexception).
From the design level, the presentation layer relies on the service layer, the service layer depends on the domain layer, if do exposed, it will lead to the display layer directly dependent on the domain layer, although still a one-way dependency, but this cross-layer dependency will lead to unnecessary coupling.

For DTOs, it is also important to note that DTOs should be a "flattened two-dimensional object", for example, if the user associates several other entities (such as address, account, region, and so on), then GetUser () Return userinfo, do you want to return the DTO of the object it is associated with? If this is the case, it will inevitably lead to a large increase in data transmission volume, for distributed applications, because of the data on the network transmission, serialization and deserialization, this design is more unacceptable. If GetUser needs to return a accountid, AccountName, RegionID, Regionname, in addition to returning the basic information of the user, define these attributes to userinfo and flatten a "stereo" Object Tree "Into a" flat two-dimensional object ", the author is currently involved in a distributed system, the system regardless of 3,721, all of an object's associated objects are converted to the same structure of the Dto object tree and return, resulting in very slow performance.

The difference between

do and Po is  
       do and PO are one by one corresponding in most cases, PO is a pojo that contains only the Get/set method, But some scenes can still reflect the conceptual difference between the two:  
do does not need to be persisted explicitly in some scenarios, such as a commodity discount strategy designed with a policy pattern, which will derive the interface of the discount policy and the implementation classes of the different discount policies, and these discount policy implementation classes can be considered do , but they reside only in static memory and do not need to be persisted to the persistence layer, so there is no corresponding PO for this type of do.  
Similarly, in some scenarios, PO has no corresponding do, such as teacher teacher and student student there are many-to-many relationships, in a relational database, this relationship needs to be represented as an intermediate table, There should be a Teacherandstudentpo po, but this PO does not have any realistic meaning in the business domain, it can not be at all with any do correspondence. In particular, it is stated here that not all many-to-many relationships have no business meaning, which is related to specific business scenarios, such as: the relationship between the two PO affects the specific business, and there are many types of this relationship, then this many-to-many relationship should also be represented as a do, such as: "Role" and "resources" There are many-to-many relationships, and the relationship is clearly represented as a do--"permission."  
In some cases, for some persistence strategy or performance consideration, a PO may correspond to multiple do and vice versa. For example, customer customers have their contact information contacts, here is a two-to-one relationship between do, but may be due to performance considerations (extreme cases, rights as an example), in order to reduce the database connection query operation, Merge the customer and contacts two do data into a single data table. Conversely, if there is one property that is a cover cover, but this property is a picture of binary data, and some query operations do not want to load cover together, thus reducing disk IO overhead, and assuming that the ORM framework does not support attribute-level lazy loading, Then it is necessary to consider cover independent into a data table, so as to form a do to deal with a PO case.  
Some property values of the PO do not make any sense to do, these property values may be to solve some persistence policy, the existence of data, for example, in order to achieve "optimistic lock", PO has a version of the properties, this version for do is not any business sense, It should not exist in do. Similarly, there may be properties in do that do not need to be persisted.

Application of Do and PO
Since the ORM framework is very powerful and has a large line, and Java EE has introduced the JPA specification, now the business application development, basically do not need to distinguish between do and po,po can be hidden in do by Jpa,hibernate ANNOTATIONS/HBM. Nevertheless, there are some problems that we must pay attention to:
For a property that does not need to be persisted, an ORM explicit declaration is required, such as: In JPA, you can take advantage of the @transient declaration.
For properties that exist in the PO for some persistence policy, such as version, because do, PO are merged, must be declared in do, but because this property has no business meaning to do, it is necessary to hide the property from the outside, the most common practice is to privatize the property's Get/set method, Does not even provide the Get/set method, but for hibernate, this requires special attention, because hibernate from the database read data to do, is to use the reflection mechanism to call do the empty argument constructor to construct a do instance, Then using the JavaBean specification to reflect the set method to set a value for each property, if you do not explicitly declare the set method, or set method to private, will cause hibernate to fail to initialize do, resulting in a run-time exception, It is advisable to set the property's set method to protected.
Hibernate provides good support for a do-to-multiple PO, or a PO for multiple do scenarios, and attribute-level lazy loading, as well as hibnate.

O/R Mapper object/relationship Mapping
After defining all the mapping, this O/R
Mapper can help us do a lot of work. Through these mappings, this O/R
Mapper can generate all the SQL statements about object Save, delete, read, we no longer need to write so many lines of DAL code.
Entity model (solid mode)
DAL (data access Layer)
Idal (interface layer)
Dalfactory (class factory)
BLL (business logic Layer)
BOF business Object Framework service objects Frame
SOA Service Orient Architecture Services-oriented design
EMF Eclipse Model Framework
Eclipse Modeling Framework

Several objects of Java (Po,vo,dao,bo,pojo) explained