addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgoogleimageimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Re: [ljc] DTO as an anti-pattern?

From: Kevin W.
Sent on: Friday, January 11, 2013 11:24 AM
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]> wrote:
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]> wrote:
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?

Pros
- 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.

Cons
- 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.

Thanks
Craig




--
Kevin Wright
mail: [address removed]
gtalk / msn : [address removed]
vibe / skype: kev.lee.wright
steam: 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

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

  • Craft Rebellion

    Your choice of fresh craft beer, delivered. For 10% off use ‘LJC'

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy