100% in agreement.
My experience here has been that people who claim that DTOs are bad are still using them in a different form. They just don't consider something defined in e.g WSDL to be a DTO.
If you change your perspective to acknowledge that something not defined in your Java source *is* still a DTO, then they're hard to argue against if you have any wish to maintain stable interfaces. This then leads quite naturally to a model using Scala case classes or classes using jackson/JAXB/WS* annotations specifically for exposure to the outside world.
So you get the benefits of having the compiler check that it all wires up correctly, without any fiddly code generation to arrange in your build scripts and configure in your IDE. Plus there's no risk of anything getting out of sync if you forgot a code generation step, because there isn't one to forget.
On 11 January[masked]:23, Colin Soho Cobra Vipurs <[address removed]>
This is something we've been back and forth on a few times now as I suspect many people have and have now ultimately decided that DTOs are a Good Thing.
Our reasoning for this is that consumers of our web services have a known specification which can be broken by refactoring domain objects if they are marshalled directly. We want to be able to refactor our domain to keep it clean yet ensure our contracts are adhered to and DTOs let us do that. It also has the benefit of the *compiler* letting us know we broke something rather than tests or our clients.
On Fri, Jan 11, 2013 at 7:07 AM, Craig Silk <[address removed]>
There's a good amount of talk about DTO's being pointless and / or DTO's being essential and a part of a well designed, loosely coupled architecture. I think both points are valid but that does leave me wondering which direction to take.
I'm taking data from a database and ultimately passing it through a web service for consumption elsewhere. My persistence layer / domain models are JPA entities annotated with JAXB annotations so the data can be marshaled into XML before being passed to the web service (this is managed by an EJB application that sits between the web services and the domain models).
I'm constantly bugged by the thought that I should be using data transfers objects (POJO's with getters and setters) to hold the data from the entities and use JAXB annotations (in the DTO's) to create the XML payload.
So my question is: use DTO's or not?
- Separation of concerns, are entities really the right place to stick JAXB annotations anyway?
- Cheerry picking data, I can create smaller DTO's that hold a subset of what an entity returns thus making it easier to marshal XML payloads with less data.
- The cost associated with replicating data.
- Breaking the DRY principle.
- Have to introduce optional annotations (and logic) that tell JAXB what to NOT marshal... does this break the KISS principle?
I would usually turn to Martin Fowler in my times of Architectural need but I've got limited web access today.
mail: [address removed]
gtalk / msn : [address removed]
vibe / skype: kev.lee.wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra