Generic DTOs
September 27th, 2009
Adam Bien presents the Generic DTO convention, where your DTOs wrap around Java Map instances.
If you are considering a generic DTO approach, you might want to investigate Protocol Buffers. Though you will have to create and maintain .proto files, you’ll gain language independence and (presumably) performance.
I just threw up in my mouth. Generic DTOs are a terrible idea (much like Struts Dynabeans or whatever they were called). Generic DTOs completely defeat the purpose of using the Java programming language (no static type checking, bad performance, no tool support). From a client perspective, you do all the work (specifying types) and get none of the benefit. If someone were to go that route, they’d be a lot better off with Ruby or Python.
+1 for protocol buffers which are statically checkable.
“With GenericDTO you, and not the compiler, are responsible for type checks. Furthermore you will have to give up auto-completion support in IDEs. … Your code will always compile – but not always run. … Working with GenericDTOs requires lot of plumbing … a GenericDTO needs an order of magnitude more instances at runtime, than an usual, type safe DTO.”
This is a joke, right? If not, heck, just throw in the towel and use Rails!
Hi,
usually in a project when the time comes to DTO or not things get worried very soon.
thank you for suggesting the protocol buffer solution. I haven’t heard about it and sound pretty interesting. But what about a simple xsd to describe your dto’s model and then let a compiler to generate the corresponding java code? You still get static type safety in a more “standard” (for a java developer) and interoperable solution. I gave a brief look at the Developer Guide
http://code.google.com/apis/protocolbuffers/docs/overview.html
and i think there is the response to my question but i would like to ear some opinions.