DTO vs VO

When dealing with database models as a java developer, we easily come across few concepts such as DTO and VO.

This article is to clarify each concepts and explain when and why we should use them.

This is pretty much conventional flow of the Spring layered architecture.

Controller ← DTO → Service ← DTO → DAO(Mapper) ← DB

DTO(Data Transfer Object), is just a java object to transfer data between each layers.

In the example of e-commerce platform, let’s say I fetch want to retrieve a detailed info about the store A.

public class Store {
    int storeSeq;
    String storeName;
    String storeAddress;
    ...(getters/setters)
}
public class StoreService {
    Store storeA = storeMapper.selectStoreByStoreSeq(storeSeq);
}

The “Store” object will transfer from Database all the way to Controller. The object is mutable.(It contains setter method).

So, we’ve established the DTO. What are VO?

To answer that question, we need to understand the realistic problems we face.

• There are some fields that cannot be released to the end users. In the example above, I want to hide storeSeq to the end users for security purposes.
• I want to make the object immutable so that the object serves its purpose of transferring data between layers, and not get changed on the way.

This is when Value Object(VO) becomes useful. Value Object, like the word implies, is an object that has value. It is immutable object with redefined equals and hashCode method.

VO is essentially a read-only object for comparing and transferring data.

It was pretty confusing for me to understand the difference between DTO and VO for a while. When you work on a side project which does not require complex and verbose codebase, DTO will do the trick most of the time. However, when the product feature gets changed or your dev members grow, separating VO from DTO will make a lot of difference in work performance.