Difference between Entity and DTO

Short answer:

• Entities may be part of a business domain. Thus, they can implement behavior and be applied to different use cases within the domain.

• DTOs are used only to transfer data from one process or context to another. As such, they are without behavior - except for very basic and usually standardised storage and retrieval functions.

Long answer:

While the term "Data Transfer Object" (DTO) is defined quite unambiguously,the term "Entity" is interpreted differently in various contexts.

The most relevant interpretations of the term "Entity", in my opinion, are the following three:

1. In the context of enterprise java and jpa:
   "An object that represents persistent data maintained in a database."

2. In the context of "domain-driven-design" (by Eric Evans):
   "An object defined primarily by its identity, rather than its attributes."

3. In the context of "clean architecture" (by Robert C. Martin):
   "An object that encapsulates enterprise-wide critical business rules."

The Jee- and Jpa-community sees entities primarily as objects mapped toa database table. This point of view is very close to the definition of a DTO- and that's where much of the confusion probably stems from.

In the context of domain-driven-design, as well as Robert Martins point of view,however, Entities are part of a business domain and thus can and shouldimplement behavior.

Difference between DTO & Entity:

Entity is class mapped to table. Dto is class mapped to "view" layer mostly.What needed to store is entity & which needed to 'show' on web page is DTO.

Example : If I want to store employee model as follows : Take employee as an example, I need to store gender either male/female/other.But on JSP I need to show all three values as form 'options' so user can select one.

@Entitypublic class Employee{//annotate with @Id and othersprivate Long id;private String name;private Gender gender; //this is enum viz Male,female}//Now extend Dto with employeepublic EmployeeDto extends Employee{Gender[] genders=Gender.values(); //put all gender types in array.}

while rendering jsp we can give

<select name="gender"> //pointed towards entity gender field.  <option value="Male">Male</option>  <option value="Female">Female</option>  <option value="Other">Other</option></select>

then in spring or some other framework whichever selected will be opted as gender in entity.This is made possible because Dto had all three values of gender in it.Similarly, as per situation things follows.As mostly we need most of entity fields on jsp we extend dto by entity.

"Entities" refer to units of composition of the overall system data. They normally represent business objects like: bank accounts, employees, products, etc. They can be used to persist the state of the system to a database.

"Data transfer objects" are emphemeral collections of data transferred for a very specific purpose. For example, to display a list of products of a specific kind to an end user. You do not want to send all of the data that represents every product entity to the user, but only what is needed for this purpose.

The the Microsoft 2014 MVC documentation explains why you would want to create DTOs from entities. These are some examples of what they suggest that you do to convert entities to DTOs.

• Remove circular references.
• Hide particular properties that clients are not supposed to view.
• Omit some properties in order to reduce payload size.
• Flatten object graphs that contain nested objects, to make them more convenient for clients.
• Avoid "over-posting" vulnerabilities. (See Model Validation for a discussion of over-posting.)
• Decouple your service layer from your database layer.

But it's important to understand that none of these are hard rules that need to be followed. It all depends on what data is best to send your client and what format would be most useful for your client.

What does the client need to do with the data?

• Will it be edited or just viewed?
• Do clients care about the order of the int list?
• Will insertions or deletions of an int need to be made?
• Will the list need to be rearranged?

Does the client need to know about the 1-1 or 1-many relationships or the fact that there's inheritance? Sending this information may be just adding unnecessary complexity for the client.

These and other questions need to be answered before deciding what data to send the client and how to send it.