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

From: Kevin W.
Sent on: Monday, January 14, 2013 11:24 AM
That's more an artefact of Java than it is of DTOs as a concept.  For example, the following comes straight from a codebase I'm working on:

object UserPageviewActivityInfo { implicit lazy val jsonFormat = jsonFormat14(this.apply) }

case class UserPageviewActivityInfo(
  timestamp: String,
  brandTitle: String,
  pageUrl: SplitUrlInfo,
  pageviews: Int,
  previousPageUrl: String,
  visitCount: Int,
  visitLength: Int,
  timeOnPage: Int,
  timeOnSite: Int,
  visits: Int,
  version: String,
  userid: String,
  authenticated: String,
  activity: String = "page view"
)

This isn't Java, it's Scala using spray-json, but that's beside the point.  What counts is that *this is an object* for the sole purpose of transferring data to a JavaScript client.  In the web app layer I simply call instance.toJson.compactPrint and send the output as the response body.  A case class is nothing more than a class in which property accessors, hashCode, equality, and toString are implemented for you by the compiler - making them perfect for exactly this kind of task.  If I mess up, the compiler will tell me.

This is every bit as clean as a Map, plus it's more type safe, decoupled from other logic, and you can even use assertions in the constructor or inherit from other types to add utility and remove duplication.  It also helps that there's now a obvious place to put factory methods for creating these things.  There's very little boilerplate, and no need for code generation or external files to specify interfaces.  I didn't mention Scala to plug it, but because it genuinely helps me focus on the essence of the concept.

Once you look past the fact that one particular implementation of DTOs in Java needs a lot of boilerplate, and understand that this isn't globally true, it makes a lot of sense.  Nor is this some special trick in Scala, you can do similar in JRuby, Groovy, or Clojure.  The same is even possible in raw Java using something like the Lombok library and a spot of reflection.



On 14 January[masked]:26, Ged Byrne <[address removed]> wrote:
Hi Craig,


That makes it easy to rule out annotating the entity objects with Jaxb directly.  That only makes sense when all clients are using the same object boundaries.  For example, if you have a canonical data model.  

The question remains: do you want to use DTOs.  With DTOs you are introducing a whole new set of classes that you have to look after.  If all you are doing is marshalling those objects into a text document to stream over a network then it will be much easier to take a dynamic approach.  For example, using a map.

I would say the only reason to go to the trouble of declaring a whole set of DTO classes is if you are going to share them with a client so that they will take advantage of static typing.  

Will you share your DTOs with a client, or will you only ever use them for generating a message document?

Regards,




Ged


On Sunday, 13 January 2013, Craig Silk wrote:
Ged - The real issue here is, is it ok to annotate entities with JAXB annotations and have to provide logic to decide what gets marshalled depending on the request or should I use DTO's to hold the data from the entities and annotate the DTO's so the whole thing gets marshalled and I can decide which DTO to populate based on what comes in the request?





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
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]




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



--
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 12/13 Jun 14

  • SkillsMatter

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

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

  • Packt Publishing

    A publishing company specializing on specific technologies and solutions

  • 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