When to use DTO pattern?

Discussions

General J2EE: When to use DTO pattern?

  1. When to use DTO pattern? (2 messages)

    Hello,

    I'm having a difficult time with the DTO pattern. I understand the need to use DTO's when you are using EJB's for performance issues and such.

    However, I'm using Hibernate with POJO's. I'm also using a Session Facade, although again not with Session Beans but with just POJO's. The session facade includes DAO-type methods and methods to wrap around the business logic contained in the domain objects. They then return the same domain objects to the view which are mapped with hibernate to use lazy queries. It's all very easy to do.

    Now, I realize the business logic contained in the domain objects are now exposed to the view, and that is the only downside I can see to this. However, I can't justify all the work involved with creating separate DTO objects, populating them, etc. in this scenario. Should I not worry about DTO's or is that always considered bad practice? Thanks.

    Threaded Messages (2)

  2. When to use DTO pattern?[ Go to top ]

    I believe this is the correct answer: There is nothing wrong with sending business-logic domain objects to the View - MVC does not specify that the model be free of business logic.

    The DTO pattern is used as a technique to avoid making RPCs, i.e. strip out all functionality and return an object with dumb getters and setters only, so the data travelling across the wire is diminished. The same principle as SOAP uses.

    So its actually only worth unloading model objects into DTOs if your View tier is on a physically remote tier to the data tier, and the objects are so large that there is a performance issue.
  3. When to use DTO[ Go to top ]

    I wish it could be as simple. Though DTO originated due to network distribution tiers of a system there can be whole load of issues if domain objects are returned to View layers. Here are some of them:

    1.By exposing Domain objects to View layer, Views become aware of structure of domain objects, which lets view makes some assumptions about how related objects are available. For example if a domain object "Person" was retunrned to a view to which it is "bound" and on some other view, "Address" of Person is to be bound, there would be a tendency for Application layer to use a semantic like person.getAddresse() which woukd fail since at that point Address domain object might have not been loaded at point. In essence, with domain objects becoming available to View layers, views can always make assumptions about how data is made available.

    2.) when domain objects are bound to views (more so in Thick clients), there will alwyas be a tendency for View centric logic to creep inside these objects making them logically corrupt.

    Basically from my experience I have seen that making domain objects available to Views create architectural issues but there are issues with use of DTO's also since use of DTO creates additional work in terms of creation of Assemblers (DTO to Domain objects and reverse), Proliferation of analogous objects like Patient domain object, Patient DTO and perhaps Patient bean bound to view.

    Clearly there are no right answers for this specially in a thick client system.