addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1linklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

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

From: Colin V.
Sent on: Friday, January 11, 2013 3:02 PM
Wesley,

I think you're agreeing with what I was saying.  Maybe!

The reasons you gave is one of the reasons I like to avoid naming things in such a way, be it DTO, DAO etc.  These things, even though they are just named and describe a function generally conjure up a very specific implementation for a lot of people.  The pattern we follow is to name our classes as <Type>View, working on the principle that what we're sending out is a specific view of an object *not* a traditional DTO

On Fri, Jan 11, 2013 at 2:44 PM, Wesley Hall <[address removed]> wrote:
Craig,

I am one of those people who has (often fairly loudly) decried DTOs as an 'anti-pattern'. This is not to say that I do not, as Kevin quite rightly says, use them in a 'different form', but I just hold that this 'different form' is much better. The reason for this is because I see a tonne of sloppy shit like...

CustomerDTO createCustomer(CustomerDTO customer);

This is horrible.

For starters, presumably your CustomerDTO has a field to contain the database ID of some created customer, it may also have some kind of status enumerated type. How are you validating these values in the parameter instance? Are there only a subset of valid statuses for records that are being created? What is the ID value? Null? -1? Are you validating this? What are you doing if someone sends you a DTO parameter that does not have a null ID or a valid 'creation' status value?

With these kinds of patterns, you always end up with a multitude of 'mapping' methods to turn one representation into another, you nearly always get bugs when a field gets added somewhere and somebody forgets to implement the mapping (everyone is TDDing right? ;)). If you are very lucky, you might also get some kind of context based validator that knows how to validate the incoming DTOs in each method that uses them.

Does anyone remember the days when we learnt that objects should be created in a consistent state and be self validating? When did we forget this?

How does this look?

CreateCustomerResponse createCustomer(CreateCustomerRequest request)

Yes, it's a similar kind of thing, but now your objects can be self validating because they are distinct and describe their specific function. The response object can use a primitive value for it's id if you are using numeric ids (despite the 'pure OO' debate, one of the nice things about primitives is they can express a 'cannot be null' intent).

If you like you can just do...

Customer createCustomer(CreateCustomerRequest request);

...but here's the rub. 'Customer' is not your entity, it becomes the canonical representation of Customer and instead your 'special' suffix goes to your entities which are actually your more specialised creations. CustomerEntity... because, why do our database mapping classes get automatic rights to the 'unmolested' noun? Aren't they just as specialised as our DTOs? More so even.

Mostly my intent here is to provide some food for thought. It seems to have become the convention to have a 'primary' entity class, and copy these fields into a <Entity>DTO class to pass the data around, but not all conventions are good ones :). I happen to think this one is fairly bad and leads to a load of cruft.

Cheers

Wes Hall



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




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Craig Silk ([address removed]) from LJC - London Java Community.
To learn more about Craig Silk, visit his/her member profile





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Wesley Hall ([address removed]) from LJC - London Java Community.
To learn more about Wesley Hall, visit his/her member profile



--
Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.

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.

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