4

I assume if you're using DTO and DAO, there is no need for entities, at least examples that i saw in this way. Or is it optional to have entities in this scenario ?

public interface CustomerResource {

    @GET
    @Path("/getCustomerListByUserID/{userID}")
    Response getCustomerListByUserID(@PathParam("userID") String userID);

    @DELETE
    @Path("/deleteCustomer/{customerID}")
    Response deleteCustomer(@PathParam("customerID") int customerID);

    @POST
    @Path("/updateCustomer")
    Response updateCustomer(CustomerDTO customer);
 }


public class CustomerResourceImpl implements CustomerResource{

 @Override
 public Response deleteCustomer(int customerID) {
     internalService.deleteCustomer(customerID);
 }

 @Override
 public Response getCustomerListByUserID(String userID) {
     internalService.getCustomerListByUserID(customerID);
 }

 @Override
 public Response updateCustomer(CustomerDTO customer) {
     internalService.updateCustomer(customer);
 }
}

public interface CustomerDAO extends BaseDAO<CustomerDTO> {
 
     List<CustomerDTO> getCustomerListByUserID(String userID);
 
     void deleteCustomer(Integer customerID);
 
     void updateCustomer(CustomerDTO customer);
 }

And internalService directly calls CustomerDAO

Are there anything wrong about this structure, how can it be better, is there any need for Customer entity?

Thank you so much ! Wish success for you all !

Hasan Durukan
  • 83
  • 1
  • 7

2 Answers2

7

In JPA, Entities vs DTOs are two different projections that can be returned from your DAO or Repository. The difference is that Entities are managed (beans) whereas DTOs are unmanaged (simple data carriers). This makes an Entity a direct representation of a database where a DTO is just a message.

  • Entity == database table (in object form) that maintains a link to the persistence layer
  • DTO == data that may (or may not) represent one or more tables but has no reference to a persistence layer

Note the "reference to a persistence layer" in modern Java is often handled through annotations.

Since people use these terms loosely and interchangeably, the JPA distinction is not always followed in conversation; but it is one clearcut way to separate definitions.

Related:

jaco0646
  • 15,303
  • 7
  • 59
  • 83
4

DTO is an abbreviation for Data Transfer Object, so it is used to transfer the data between classes and modules of your application.

DTO should only contain private fields for your data, getters, setters, and constructors. DTO is not recommended to add business logic methods to such classes, but it is OK to add some util methods. DAO is an abbreviation for Data Access Object, so it should encapsulate the logic for retrieving, saving and updating data in your data storage (a database, a file-system, whatever).

Here is an example of how the DAO and DTO interfaces would look like:

interface PersonDTO {
    String getName();
    void setName(String name);
    //.....
}

interface PersonDAO {
    PersonDTO findById(long id);
    void save(PersonDTO person);
    //.....
}

@Entity
public class Person {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@NotNull
protected String name;
...getter and setter
}

An entity is a lightweight persistence domain object. Typically, an entity represents a table in a relational database, and each entity instance corresponds to a row in that table.

  • I seen all of these before, i understand the meaning of each, what i am asking for is "if we transfer data by dto and acces it by dao what is the reason of entity is it just for persistance, and if it is never initialize an entity object is ok ? – Hasan Durukan Nov 05 '21 at 13:36
  • yes is to have different layer - Entity is just for persistence - database – Andrea Cavallo Nov 05 '21 at 13:40