1. Overview
In this tutorial, we’ll learn what Data Transfer Object (DTO), Value Object (VO), Plain Old Java Object (POJO), and JavaBeans are. We will look at the differences between them and understand which type to use and when.
2. Plain Old Java Object
POJO, also known as Plain Old Java Object, is an ordinary Java object that does not have references to any particular framework. It’s a term used to refer to a simple, lightweight Java object.
A POJO does not use any naming convention for properties and methods.
Let’s define a basic EmployeePOJO object that has three properties:
public class EmployeePOJO {
private String firstName;
private String lastName;
private LocalDate startDate;
public EmployeePOJO(String firstName, String lastName, LocalDate startDate) {
this.firstName = firstName;
this.lastName = lastName;
this.startDate = startDate;
}
public String name() {
return this.firstName + " " + this.lastName;
}
public LocalDate getStart() {
return this.startDate;
}
}
As we can see, the above Java object defines the structure to represent an employee and does not depend on any framework.
3. JavaBeans
3.1. What Is a JavaBean?
A JavaBean is mostly like a POJO, with some strict set of rules on how to implement it.Â
The rules specify that it should be serializable, have a null constructor, and allow access to variables using methods that follow the getX() and setX() convention.
3.2. POJO as a JavaBean
Since a JavaBean is essentially a POJO, let’s convert EmployeePOJO to a JavaBean by implementing the necessary bean rules:
public class EmployeeBean implements Serializable {
private static final long serialVersionUID = -3760445487636086034L;
private String firstName;
private String lastName;
private LocalDate startDate;
public EmployeeBean() {
}
public EmployeeBean(String firstName, String lastName, LocalDate startDate) {
this.firstName = firstName;
this.lastName = lastName;
this.startDate = startDate;
}
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
// additional getters and setters
}
Here, in order to convert the POJO into a JavaBean, we’ve implemented the Serializable interface, marked properties as private, and used getter/setter methods to access the properties.
4. DTO
4.1. The DTO Pattern
A DTO, also referred to as Data Transfer Object, encapsulates values to carry data between processes or networks.
This helps in reducing the number of methods called. By including multiple parameters or values in a single call, we reduce the network overhead in remote operations.
One more advantage of this pattern is the encapsulation of the serialization’s logic. It lets the program store and transfer data in a specific format.
A DTO does not have any explicit behavior. It basically helps in making the code loosely coupled by decoupling the domain models from the presentation layer.
4.2. How to Use DTO?
DTOs have flat structures without any business logic. They use the same format as that of POJOs. A DTO only contains storage, accessors, and methods related to serializing or parsing.
DTOs basically map to a domain model and thus send data to a method or a server.
Let’s create the EmployeeDTO that groups all the necessary details to create an employee. We’ll send this data to a server in a single request that optimizes the interactions with the API:
public class EmployeeDTO {
private String firstName;
private String lastName;
private LocalDate startDate;
// standard getters and setters
}
The above DTO interacts with different services and handles the flow of data. This DTO pattern can be used in any service without any framework limitations.
5. VO
VO, also known as the Value Object, is a special type of object that can hold values such as java.lang.Integer and java.lang.Long.
A VO should always override the equals() and hashCode() methods. VOs generally encapsulate small objects such as numbers, dates, strings, and more. They follow the value semantics, i.e., they directly change the object’s value and pass copies around instead of references.
It’s a good practice to make Value Objects immutable. The change in values occurs only by creating a new object and not by updating values in the old object itself. This helps in understanding the implicit contract that two Value Objects created equal should remain equal.
Let’s define EmployeeVO and override the equals() and hashCode() methods:
public final class EmployeeVO {
private final String firstName;
private final String lastName;
private final LocalDate startDate;
public EmployeeVO(String firstName, String lastName, LocalDate startDate) {
this.firstName = firstName;
this.lastName = lastName;
this.startDate = startDate;
}
// Getters
@Override
public boolean equals(Object obj) {
if (this == obj) return true;
if (obj == null || getClass() != obj.getClass()) return false;
EmployeeVO emp = (EmployeeVO) obj;
return Objects.equals(firstName, emp.firstName)
&& Objects.equals(lastName, emp.lastName)
&& Objects.equals(startDate, emp.startDate);
}
@Override
public int hashCode() {
return Objects.hash(firstName, lastName, startDate);
}
}
6. Conclusion
In this article, we saw the definitions of POJO, JavaBeans, DTO, and Value Objects. We also saw how some frameworks and libraries harness the JavaBean naming conventions and how to convert a POJO to a JavaBean. We also had a look at the DTO pattern and Value Objects along with their usage in different scenarios.
Next, Java 14 records enhance the readability by abstracting getters, setters, equals and hashcode and provide immutability out-of-the-box. You can read more about it in our article here.
As always, the code for these examples is available over on GitHub.
