2
2
.
.
2
2
.
.
3
3
D
D
a
a
t
t
a
a
T
T
r
r
a
a
n
n
s
s
f
f
e
e
r
r
O
O
b
b
j
j
e
e
c
c
t
t
(
(
D
D
T
T
O
O
)
)
I
I
n
n
f
f
o
o
[
[
R
R
]
]
Data Transfer Object (DTO)
● contains data that should be transferred between application layers (but not between application and DB)
● is used as a replacement for Entity when not all Entity Properties need to be sent
Just like Entity, Command Class should only have
● Properties that are equivalent to Table Columns
● Setters and getters for setting and reading these Properties
● Optional Constructor for settings all of these properties at once
Command Class should not have any logic (just pure data to transfer over layers/network).
It also shouldn't contain any methods for converting between Command and Entity Objects.
These methods should be implemented inside Converter Object.
For example, if Table has 100 Columns, then corresponding Entity will have 100 Properties.
But if we need to display only 10 Properties on our interface, these can be encapsulated inside the Command Object.
Now our backend can send Command Object with only 10 Properties to our front end (instead of sending Entity with 100
Properties).
Command (DTO) serves similar purpose to Entity (DO)
● Command (DTO) is used when beck-end wants to send/retrieve data to front-end
● Entity (DO) is used when beck-end wants to send/retrieve data to DB
If your Entity Object is small enough and if it doesn't contain any sensitive data, it can be sent directly to the front-end.
In that case you wouldn't need neither Converter (DCO) nor Command (DTO).
D
D
T
T
O
O
v
v
s
s
E
E
n
n
t
t
i
i
t
t
y
y
The best way to understand difference between DTO and Entity is to create DTO that contains data for multiple Entities.
Service will then extract data from DTO in order to create distinct Entities that can be stored into DB.
For instance HTML Form might be used to enter both Author and Book data.
Inside Controller such HTTP Request is converted into DTO and forwarded to Service.
In order to save Author and Book as separate Entities Service must extract relevant data from DTO.
DTO can contain data for one or more Entities which are used to create those Entities.
This means that DTO should be converted into Entities.
Conversion is usually done through Mapper Class that maps DTO Properties into Entity Properties with the same name.
Properties that are missing in DTO but exist in Entity remain empty in Entity.
DTO conversion into Entities
AUTHOR_BOOK_DTO
NAME
AGE
TITLE
AUTHOR_ENTITY
NAME
AGE
PRIMARY KEY
BOOK_ENTITY
TITLE
PRIMARY KEY
W
W
h
h
e
e
n
n
t
t
o
o
u
u
s
s
e
e
D
D
T
T
O
O
(
(
i
i
n
n
s
s
t
t
e
e
a
a
d
d
E
E
n
n
t
t
i
i
t
t
y
y
)
)
[
[
R
R
]
]
DTO decouples front-end from the Domain Model.
With DTO changes to Domain Model don't need to influence front-end since DTO might remain the same.
Also DTO can contain data from multiple Entities making it easier to send all of that data in one go.
Exposing Domain Objects to the UI is a bad idea because as the application grows the needs for
● UI change and force your Domain Objects to accommodate those changes
● Domain Objects change and force your UI to accommodate those changes
In other words your Domain Objects end up serving 2 masters which address different needs of the application
● User Interface (UI) which has the function of communicating with the user
● Domain Model which holds business rules and stores data
If you return part of your Domain Model to the front-end then Domain Model becomes part of a contract with front-end.
This is problematic because a contract is hard to change (since things outside of your context depend on it).
Therefore you would be making part of your Domain Model hard to change.
Because every change would need to be propagated all the way to the front-end.
Very important aspect of Domain Model is that it is easy to change.
This makes us flexible to the domain's changing requirements.
W
W
h
h
e
e
n
n
t
t
o
o
u
u
s
s
e
e
E
E
n
n
t
t
i
i
t
t
y
y
(
(
i
i
n
n
s
s
t
t
e
e
a
a
d
d
D
D
T
T
O
O
)
)
At the beginning of the Project you might decide to use only Entities.
This way you don't have to change two things every time a new change is requested.
Also during development you will probably use test data so there is no need to protect sensitive data.
Even after the Project is finished you don't have to have DTO for every Entity.
If you need to return single Entity which is small and has no sensitive data you don't need to create DTO for it.
If at later time front-end and back-end requirements start to diverge you can simply introduce DTO which will look like
the current Entity and then add changes to the Entity so that they can continue to live independently.
But no matter if you use Entity or DTO for communication between front-end and back-end you will always need Services.
This is because Service Layer contains business logic and it is always good to have it encapsulated separately.
