Understanding DTO, BO, PO, VO: When and How to Use Each in Java Backend

Definitions

DTO (Data Transfer Object) – a plain object that carries data between layers or services. It contains only fields required for a specific use case and no business logic.

BO (Business Object) – an object in the business‑logic layer that may encapsulate multiple entities and contains validation or transformation logic before the data reaches the service layer.

PO (Persistent Object) – an object that maps one‑to‑one to a database table row. It is used by ORM frameworks (e.g., MyBatis, JPA) for CRUD operations.

VO (Value Object) – an object tailored for the view layer. It presents only the data needed by the client, often a subset or a reshaped version of the DTO.

Typical Java Class Illustrations

Persistent Object (PO) representing a user table:

@Data
public class User implements Serializable {
    private Long id;
    private String username;
    private String password;
    private String identityCard;
    private String gender;
    private String location;
    private String userImage;
    private String phoneNumber;
    private String createTime;
    private String updateTime;
    @TableLogic
    private int isDelete;
}

Data Transfer Object (DTO) used as the entry point for a module:

@Data
public class UserDTO implements Serializable {
    private Long id;
    private String username;
    private String password;
    private String identityCard;
    private String gender;
    private String location;
    private String userImage;
    private String phoneNumber;
}

Business Objects (BO) that filter/validate data received from the DTO before the service layer:

@Data
public class UserLoginBO implements Serializable {
    private String username;
    private String password;
}

@Data
public class UserUpdateBO implements Serializable {
    private Long id;
    private String username;
    private String password;
    private String identityCard;
    private String gender;
    private String location;
    private String userImage;
    private String phoneNumber;
}

Backend Flow Using DTO/BO/PO

Client sends a request → data is deserialized into UserDTO .

Controller converts UserDTO to a specific BO (e.g., UserLoginBO or UserUpdateBO ) to enforce business rules and boundary checks.

Service layer processes the BO and, before persisting, transforms it into a User PO that matches the database schema.

DAO/Mapper persists the PO.

Why a Separate VO May Be Omitted

If a DTO is configured to omit null fields during JSON serialization, the same DTO can be returned to the front‑end without exposing unwanted data. This reduces the need for an extra VO class.

Global Null‑Value Filtering Configuration (Spring MVC)

@Configuration
public class GlobalConfig extends WebMvcConfigurationSupport {

    @Override
    protected void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        super.configureMessageConverters(converters);
        converters.add(mappingJackson2HttpMessageConverter());
    }

    /**
     * Custom MappingJackson2HttpMessageConverter that ignores null fields.
     */
    private MappingJackson2HttpMessageConverter mappingJackson2HttpMessageConverter() {
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false);
        objectMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
        return new MappingJackson2HttpMessageConverter(objectMapper);
    }
}

This configuration ensures any null property in a DTO is omitted from the JSON response, achieving the same effect as a dedicated VO.