Been trying to come up with a flow for a basic tiered web application, and have been reading conflicting information online. What I'm trying to figure out is if there is an advantage to still using DTO objects from your DAO to Service layer through the use of some sort of mapper.

The basic flow I foresee is as follows:

  1. UI Model / Form --> Controller
  2. Controller converts Model into Domain Object (Entity)
  3. Domain Object --> Service Layer
  4. Domain Object --> DAO
  5. DAO --> Domain Object(s)
  6. Service --> UI
  7. UI converts Domain into UI models

If DTO was followed DAO would pass back a DTO not the Entity. After doing some reading it seems like DTO has become slightly defunct since (at least in Java) entities have become annotated POJOs meaning their memory footprint has become very small.

Is this the case, or should DTOs be used to completely encapsulate the domain objects within the DAO layer, and, if this is the case, what would the service layer pass to the DAO?

Thanks a bunch!

2 Answers 2


According to me, passing a persistable POJO, like for instance a bean managed by JPA, is not THE good practice.


I see three main reasons:

  1. Potential issue with lazy collections. http://java.dzone.com/articles/avoid-lazy-jpa-collections
  2. Entity should contain behaviour (in contrary of an Anemic domain model) You may not want to let your UI call some unexpected behavior.
  3. In case of anemic domain model you may not want to expose your model structure to the UI, since every new change to model may break UI.

I prefer letting my service layer convert entities to corresponding DTO in both directions. DAO still returning entity (it's not its job to ensure the conversion).

  • So if I'm understanding this correctly, the service essentially deals only with DTO objects, and acts as the intermediary of both UI and DAO. Also, on point 3, you still have to convert your DTO to workable UI elements, so wouldn't a domain update still break the UI due to DTO also needing an update.
    – dardo
    Commented May 17, 2013 at 16:17
  • 1
    @dardo UI elements ARE DTO, or at worst, should be convert to DTO before calling some services on server-side. DTO aren't likely to often change, there are just adaptation from your entities focused on UI needs. Besides, service layer should care about both: DTO and entities.
    – Mik378
    Commented May 17, 2013 at 16:21
  • Ah ok, there's the hiccup I wasn't understanding. Anemic domain model is pretty common where I work, and I'm trying to shift the paradigm a bit to encourage a thinner service layer. Thanks again!
    – dardo
    Commented May 17, 2013 at 16:26
  • @dardo You may read this book. (or show it to your company ;)) Great great book: amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/…
    – Mik378
    Commented May 17, 2013 at 16:29
  • actually got this one on kindle, amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/… pretty good so far =D
    – dardo
    Commented May 17, 2013 at 16:38

One of the reasons I think this discussion comes up repeatedly is because it seems like a serious pain-in-the-ass to take an object with all the data you need and convert it to an object that looks identical or nearly identical to the one you are handing off.

It's true, it's a PITA. But there are a few reasons (besides those enumerated above) for doing so.

  • Domain objects can get very heavy and contain a lot of useless information for the call. This bloat slows down the UI because of all the data transmitted, marshalled/unmarshalled and parsed. When you consider a FE will have numerous links referring to your webservices and being called with AJAX or some other multi-thread approach you will quickly make your UI sluggish. All this gets to the general scalability of webservices
  • Security can easily be compromised by exposing too much data. At a minimum you could expose email addresses and phone numbers of users if you don't eliminate them from the the DTO result.
  • Practical considerations: For 1 object to parade as a persisted domain object AND a DTO it would have to have more annotations than code. You will have any number of issues with managing the state of the object as it passes through layers. In general this is be much more of a PITA to manage then simply doing the tedium of copying fields from a domain object to a DTO.

But, you can manage it fairly effectively if you encapsulate the translation logic into a collection of converter classes

Have a look at lambdaJ where you can do 'convert(domainObj,toDto)' there is an overload of this for use with collections. Here is an example of a controller method that makes use of it. As you can see, it doesn't look so bad.

    public RestaurantSurveys getSurveys(@PathParam("id") Restaurant restaurant, @QueryParam("from") DateTime from, @QueryParam("to") DateTime to) {

        checkDateRange(from, to);

        MultiValueMap<Survey, SurveySchedule> surveysToSchedules = getSurveyScheduling(restaurant, from, to);
        Collection<RestaurantSurveyDto> surveyDtos = convert(surveysToSchedules.entrySet(), SurveyToRestaurantSurveyDto.getInstance());
        return new RestaurantSurveys(restaurant.getId(), from, to, surveyDtos);

  • Thanks for the input, and my thinking is along the same lines =)
    – dardo
    Commented May 17, 2013 at 20:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.