JavaEE 7 Retired The DTO

The classic DTO solves the following problem:

"You want to transfer multiple data elements over a tier."

Back in the days a DTO was implemented as a Serializable anemic Java class only equipped with field accessors.

In Java EE the became a de-facto standard for remoting, so the implementation of Serializable interface is no more required. To transfer data between tiers in Java EE 7 you get the following options for free:

  1. JAXB: the popular application servers offer JSON, XML serialization for "free".
    @NamedQuery(name = Registration.findAll, query = "SELECT r FROM Registration r")
    public class Registration {
        private static final String PREFIX = "";
        public static final String findAll = PREFIX + "all";
        private long id;
        private BiFunction<Boolean, Integer, Integer> taxCalculator;
        private int numberOfDays;
        private int numberOfAttendees;
        private boolean vatIdAvailable;
    [ from]
  2. With the introduction of Java API for JSON Processing, you can also directly serialize parts of your objects into JSON:
    public class HealthResource {
        ServerWatch watch;
        public JsonObject availableHeap() {
     JsonObjectBuilder builder = Json.createObjectBuilder();
    	builder.add("Available memory in mb",
    	add("Used memory in mb",;
    [ from project ping]

Both approaches transport the data without any binary coupling to the origin object. The decoupling is even higher, as it was the case with the "traditional" (=code duplication) DTO implementation.

[See also an in-depth discussion in the "Real World Java EE Night Hacks--Dissecting the Business Tier" book, page 273 in, chapter "Data Transfer Object"]

See you at Java EE Workshops at MUC Airport or on demand and in a location very near you:!


What if you want to share your TOs with clients?

What if REST tier is developed by other developers than persistence layer?

Posted by S on August 25, 2014 at 12:35 PM CEST #

Hi, Adam.

being no longer necessary to transfer my DTO over tiers, once I can annotated my object and make their data being transfered as a XML or JSON representation. But the abstraction created with the DTO (to simplify my domain to my client) its still useful in some cases, don't you think? So, how am I going to name this object? Maybe just a case of over dependency on suffixes, but I confess this question is bugging me.

Posted by Vinicius on August 26, 2014 at 04:25 AM CEST #

Hi Vinicius,

see also:

Join the discussion at the next:



Posted by Adam Bien on August 26, 2014 at 06:19 AM CEST #

It is true as long as
1) REST is your endpoint
2) your domain model is to be exposed in the same shape as persisted (thus like the entities are bound to be written).
The moment when your clients are pure Java - even if transport is made by REST (but you would probably be better with hessian) you still will need some objects to deserialize to - and I'd rather not have my business logic exposed in public interface of my service, so I don't want my non-anemic entities on the client side :).

Posted by psychollek on August 27, 2014 at 10:36 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments