views:

107

answers:

1

We're to use DTO's to send data to and from the presentation layer.

I have a method on a service object called PostAd which posts an advertisement entered by a user. The Ad has an association to another object called AdValues, which contain values for the Ad (title, price, description etc)

@Entity
public class Ad {
   @OneToMany
   Set<AdValue> values ...
   ...

I'm wondering what is better as far as the DTO architecture goes:

  1. have two DTO's one called AdDTO and the other called AdValuesDTO and call the PostAd method as PostAd(AdDTO, AdValuesDTO) ~or~

  2. Have an AdDTO that contains the AdValuesDTO mimicking the entity structure... this involves having DTO's within DTO's:

    AdDTO {
      Set<AdValuesDTO> adValues ...
    

Then the PostAd method is called as PostAd(AdDTO)

Or is there another alternative?

+2  A: 

Both would work but with the later approach, you could also use the DTOs to send data from the server to the client. And since having DTOs is already hard and expensive to maintain, you don't really want to multiply them like Jesus with bread.

So, to my experience, when you use DTOs, you actually end up having a symmetric structure in parallel of your Entities that you can use in both directions between the client and server. And this makes the use of a mapping solution like Dozer possible, or at least easier (and anything that makes using DTOs less painful is welcome).

Pascal Thivent
thanks, i took your advice, added dozer to my POM, and managed to delete 75% of the boiler plate code..
Billworth Vandory