A few words to understand POJO, JavaBean, EJB, DAO, DTO, VO, PO, BO, Do__java

A few words to understand POJO, JavaBean, EJB, DAO, DTO, VO, PO, BO, do


1. POJO
POJO (Plain old Java Object) is called by Martin Fowler, Rebecca Parsons and Josh Mackenzie in a speech in 2000. According to Martin Fowler, "Plain old Java object" is literally translated as "pure old-fashioned Java objects," but everyone uses "simple Java objects" to address it. The implication is that there are some private parameters that act as properties of the object, and then define the get and set methods for each parameter for outside access, without inheriting from any class, without implementing any interfaces, or by any Java object that has been invaded by other frameworks.

public class User {  
  
    private String name;  
    private int age;  
  
    Public String GetName () {return  
        name;  
    }  
  
    public void SetName (String name) {  
        this.name = name;  
    }  
  
    public int getage () {return age  
        ;  
    }  
  
    public void Setage (int age) {  
        this.age = age;  
    }  
  
}

2. JavaBean
JavaBean is a reusable component written in the Java language. JavaBean Java classes that conform to certain specifications are not a technique, but a specification. For this specification, we summarize a lot of development techniques and make a lot of components or tools. Classes that conform to this specification can be used by other programmers or frameworks.
Its method name, construction and behavior must conform to the following specific conventions:
(1) All attributes are private.
(2) This class must have a public default constructor. That is, a constructor that provides no parameters.
(3) The properties of this class are accessed using getter and setter, and other methods conform to the standard naming conventions.
(4) This class should be serializable. Implements the Serializable interface.
Because these requirements are conventions rather than implementations, many developers view JavaBean as a pojo to comply with a specific agreement.

The public class UserInfo implements java.io.serializable{ 
 
    //Implements Serializable interface.  
    private static final long serialversionuid = 1L;  
 
    private String name;  
    private int age;  
      
    The parameterless constructor public  
    UserInfo () {} is public  
	
    String getName () {return  
        name;  
    }  
  
    public void SetName (String name) {  
        this.name = name;  
    }  
  
    public int getage () {return age  
        ;  
    }  
  
    public void Setage (int age) {  
        this.age = age;  
    }  
  
    JavaBean can have other methods public  
    void Userinfoprint () {  
        System.out.println ("");  
    }  
	

The difference between Pojo and JavaBean:
Pojo is a simpler class or interface than the JavaBean. Pojo strictly adheres to the concept of simple objects, while some javabean tend to encapsulate some simple logic. Pojo format is used for temporary delivery of data, it can only load data, as a carrier of data storage, and does not have the ability to handle business logic. JavaBean Although the data acquisition and Pojo the same, but JavaBean can have other methods.


3. DAO, DTO, VO, PO, BO
DAO (Data Access Objects) is an object in which the DAO generally has an interface and an implementation class for that interface. Implementation classes are generally used to manipulate the database, such as the database for the search and other operations, the use of the general direct call to the public class DAO.
DTO (data Transfer object), VO (Value object), PO (Persistent object), DAO will pojo persisted as a po, with a PO to correspond to multiple VO and DTO, as illustrated below.
A table has 100 fields, and the corresponding PO contains the 100 properties. If the front-end interface requires only 10 property values to be displayed, then the backend does not have to pass the entire PO object to the client, so we can use the DTO with only these 10 attributes to pass the result to the client, which does not expose the service-side table structure. When the data arrives at the client, a data object is formed, the interface renders the data, and the data object is VO.
Bo (Business object) is the embodiment of Pojo in the business layer, for business operations, more is to wrap objects from the business, such as a user Bo, may include name, age, sex, privilege, group, etc., These properties may be in multiple tables in the database because each table corresponds to a PO, and Bo needs these PO combinations (or regroup) to become a complete object on the business.


4. EJB

EJB (Enterprise JavaBean) EJB is a group of JavaBean, combined to achieve the business logic of an enterprise group, which is not a simple combination, is a Concord match to achieve a business function. For example, a dress, including a hat, a piece of clothing, a pair of trousers, two shoes, this dress is an EJB, the other is a javabean.

---------------------------------------------------------------------------------------------

The following is specifically explained under Vo, DTO, do, PO four relations between

Four types of entity classes in the domain model: VO, DTO, do, PO.
Often come into contact with the concept of vo,do,dto, this paper analyzes these concepts from two angles of the entity division in the domain modeling and the actual application in the project.
The main conclusions are: In the project application, VO corresponds to the data (form) that is to be displayed on the page, and do corresponds to the data stored in the database (datasheet), and the DTO corresponds to the data that needs to be passed in addition to the two.

First, Entity class
In the day-to-day development of Java Projects, Entity (entity classes) are essential, they generally have a lot of attributes, and have the appropriate setter and getter methods. Entity (entity classes) are typically mapped to data tables.
And then look at Baidu Encyclopedia for the definition of entity classes:
The primary responsibility of an entity class is to store and manage information within the system, and it can behave or even complicate behavior, but these behaviors must be closely related to the entity objects it represents.
Based on the above definitions, we can see that the entity classes have 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 attribute and the attribute corresponding set and get method, the entity class common method also has for the output own data the ToString method.


Ii. entity classes in the domain model
The entity classes in the domain model are divided into four types: VO, DTO, do, PO, various entity classes for the interaction between different business levels, and in the hierarchy to achieve the transformation between the entity classes.
Business tiering is: View Layer (view+action), service layer (services), persistence layer (DAO)
The transfer of entities between the corresponding layers is shown below:


We do not strictly follow this transitive relationship in the project, but this association with the business level is helpful in understanding the role of the entity classes. (We have no contact with the PO for reasons I understand that ORM is encapsulating the PO)
The following is the original text of the data, which is based on this drawing.
Concept:
VO: A View object that is used by the presentation layer to encapsulate all the data of a specified page (or component).
DTO (Data Transfer object): Data Transfer object, this concept originates from the Java EE design pattern, the original goal is to provide the coarse granularity data entity for the EJB distributed application, reduces the distributed call the number of times, thus enhances the distributed invocation the performance and reduces the network load, But here, I refer to the data transfer object between the presentation layer and the service layer.
Do (domain object): domain object, is a tangible or intangible business entity abstracted from the real world.
PO (PersistentObject): A persisted object that forms a one by one mapping relationship with the data structure of the persistence layer (usually a relational database), and if the persistence layer is a relational database, then each field (or several) in the datasheet corresponds to one (or several) of the PO's attributes.

The following sequence establishes a simple model to describe the position of the above object in the three-tier architecture application.
1. The user makes a request (possibly filling out a form) and the form's data is matched to VO at the presentation level.
2. The presentation layer converts VO to the DTO required by the service layer corresponding method and transmits it to the service layer.
3. The service layer starts by constructing (or rebuilding) a do based on the data of the DTO, calling the Do business method to complete the specific business.
4. The service layer converts do to the PO corresponding to the persistence layer (you can use ORM tools or not), call the persistence layer's persistence method, pass the PO to it, and complete the persistence operation.
5. For a reverse operation, such as reading data, it is also converted and transmitted in a similar way, slightly.

Iii. entity classes in the project
Common entity classes in projects have Vo,do and DTO, and naming rules often end with the corresponding string, such as *vo. Java. But the DTO does not always follow this rule, and it usually has something to do with his use, such as *query.java, which means that a query condition is stored. The business level of the entity classes in the project is less stringent, for example, we can assemble a do at the view level, or we can get a vo out of the persistence layer, so the partitioning method associated with the business hierarchy appears to be somewhat redundant. The understanding abstracted from the project code is that VO corresponds to data that is stored in the database, and that the DTO corresponds to data that needs to be passed in addition to the two.

Reference: http://blog.csdn.net/paincupid/article/details/49924299/