If you are a Java Developer you might have heard of a lot of the following acronyms such as:
… and you probably have not much idea of what they mean actually.
Here, in this article i am going to briefly explain what these acronym stands for and for what they represent.
This is perhaps the most common acronym within the Java Development world. I mean, i am sure everyone has heard the term ‘DTO’ at some point.
DTO basically stands for Data Transfer Object. It is a very common software development pattern especially within the Java world. In fact, many argue that it originated from the Java world of enterprise development.
It is an encapsulated object that contains data to be transferred from one location to another location. When DTO first came about, it was mainly used for encapsulating data fetched from the database and use it as a transfer mechanism to the caller class.
Nowadays, it is more commonly used in a variety of places. From the Data layer (as originally used) to the Web layer where people use it as a Request/Response type object for transferring data between end user clients and the ‘view’ within the Web layer or between user API request to the backend HTTP RESTful or Non-RESTful web services.
A deep dive of this pattern is not within the scope of this article so if you want to know more about this pattern, i really encourage to take a read at my article below on my thoughts on this DTO pattern:
Another very common pattern which is denoted by the use of an acronym is the DAO pattern.
DAO represents Data Access Object.
Similar to a DTO, DAO resides in the Data layer where its main responsibility is to encapsulate the database access.
DAO is mostly visible in a more traditional enterprise-like Java project.
It is less used these days in modern software development in particular when it comes to Java development. That is because, these days people normally use Spring Boot for bootstrapping Java web apps and Spring’s Spring Data project offers the use of the Repository pattern to encapsulate database access.
So by using the Repository design pattern, there is pretty much no need to manually write your DAOs thereby making the DAO pretty much redundant.
You can read a more detailed explanation of the DAO pattern here:
PO stands for Persistence Object.
In the context for DAOs and DTOs usage within the Data layer, you might commonly also make the use of POs.
Persistence Object in its simplest terms is an object that encapsulates data to be stored into the database — hence its name ‘Persistence Object’ as it is an object supposed to be persisted to the underlying database.
POs go hand in hand with the usage of DAOs and DTOs to be honest. Whilst DTOs are commonly used as an object that stores data retrieved from the database, a PO is an object that goes the other direction — to be persisted to the database as already been mentioned.
In the field of Object Relational Mapping (ORM) you might have come across the notion of an ‘Entity Object’. A PO is basically an Entity Object. They are commonly used interchangeably.
SO is Service Object.
In a typical layered application architecture you would have 3 different layers:
- Presentation/View Layer
- Service/Business Layer
- Data Access/Persistence Layer
The Presentation or View layer would consists of all your ‘Web’ or ‘Rest’ classes who are responsible for the interface to incoming requests.
Data Access or Persistence Layer as the name suggests, is simply a layer for encapsulating the data related logic and it is this layer where both the DAO and DTO patterns really resides.
Finally, the Service Layer is the layer responsible for the core business logic and hence this is where the Service Object lives.
The Service Object (SO) is simply an object for encapsulating business logic.
A common example of this SO would be a Service Class. For e.g.
BO is Business Object.
It is an object that contains the business logic code. To put simply, BO is pretty much a SO. It is only a matter of terminology within the enterprise Java world.
However, some developers also use BO elsewhere. You might have seen classes that contains a lot of business logic but doesn’t really be classified as a ‘Service Object’ simply because it doesn’t expose ‘Service’ layer contracts to the calling Web Layer’s REST controllers.
This is where a BO diverge from a SO. Where as you can place business logic code in a SO to effectively turn a SO into a BO as well, you might consider abstraction the business logic code out into its own class — the BO. And leave the SO itself to be the ‘facade’ or ‘orchestrator’ of a number of individual business objects.
VO stands for Value Object. It is basically an object that represents a ‘value’ of a thing.
For example, “Money” can be represented as a value object like the following:
Money is a good example of a Value Object as ‘money’ would include a composition of a few attributes that makes up the object. It would have not just the monetary amount (represented as maybe a BigDecimal or a Double in Java) but also the currency (e.g. think GBP, USD etc).
Also, VOs are normally immutable meaning that they won’t be changed once created. This enables us to represent the ‘value’ properly. Since VOs are meant for easy disposable, you can create new VOs if you ever need a different ‘value’.
VOs can be used anywhere across all the layers within a layered architecture as it does not belong to a single particular layer like the DAO or DTO does.
Here’s a quick summary of those terms:
- DTO — Data Transfer Object
- DAO — Data Access Object
- PO — Persistence Object
- SO — Service Object
- BO — Business Object
- VO — Value Object