Rest controller - design

[Prasanna Raman]

I came across a Controller class at work that looks something like this:

public ResponseObject someMethodName (OrdersDTO ordersDTO)

class OrdersDTO {
    private List<OrderDTO> list = new ArrayList();
}

class OrderDTO {
    private String item;
    private String quantity;
    ......
}

Aside from the bad names, I wonder why they are taking in an object that encapsulates a List of orders, rather a List of orders directly in the Controller. Is this a good way of doing this?

If not, what's the best way to do this?

[Tim Holloway]

Well, if I understand the question properly, it's because you have two different functionalities: a Controller and a Model (List of Order). And separating Model, View (if applicable) and Controller is a proven way to provide reliable solutions, enhance testability and facilitate code re-use.

[Stephan van Hulst]

I think Prasanna's point is, why not use List as the model directly, instead of wrapping it in another DTO?

One reason that I can think of is that the designers wanted it to be forward compatible. Maybe they intend to add more properties later.

It's probably a matter of taste. I'd use the List as a parameter directly.

[Prasanna Raman]

Hello Tim,

My question was why an object (that encapsulates a List) , is passed to the Controller and not the List itself directly?

[Prasanna Raman]

Stephan van Hulst wrote:I think Prasanna's point is, why not use List as the model directly, instead of wrapping it in another DTO?

One reason that I can think of is that the designers wanted it to be forward compatible. Maybe they intend to add more properties later.

It's probably a matter of taste. I'd use the List as a parameter directly.

Thank you Stephan. Is the DTO suffix standard and one that is still followed? I see the code base littered with these. So I am forced to create new classes also following the convention.

[Ron McLeod]

It could have been used to drive the structure of the serialized data in the JAX-RS response to be a specific representation.

OrdersDTO

@Produces(MediaType.APPLICATION_JSON)
@GET
public Response test() {
	OrdersDTO ordersDTOInstance = ...

	return Response.status(Status.OK).entity(ordersDTOInstance).build();
}

serializes as{  "list": [    {      "item": "book",      "quantity": "6"    },    {      "item": "tires",      "quantity": "4"    },    {      "item": "coffee",      "quantity": "1"    }  ] }

List<OrderDTO>

@Produces(MediaType.APPLICATION_JSON)
@GET
public Response test() {
		List<OrderDTO> orderList = ...

		return Response.status(Status.OK).entity(orderList).build();
}

Serializes as[   {      "item":"book",      "quantity":"6"   },   {      "item":"tires",      "quantity":"4"   },   {      "item":"coffee",      "quantity":"1"   } ]

[Tim Holloway]

A DTO is a Data Transfer Object.

In EJB versions 1 and 2, the EJBs were not POJOs and could only be used in specific contexts. To get the values to and from EJBs from non-EJB contexts a DTO which was more or less a POJO equivalent to the DTO was needed. DTOs were one of the J2EE Design Pattern objects.

With EJB3/JPA, that is no longer the case. JPA entities are POJOs and can be used anywhere a POJO can be used, although they do have to be "attached" before they can be persisted. So that use for a DTO is eliminated. I can't actually think of any other situation in any of the standard frameworks where a DTO would be needed now.

On the other hand, I've learned that often when I act on a web page that I have a "working set" of inter-related detached Entities. This set generally has an anchor entity which means that my persistence service methods typically consume one parameter (the working set anchor, which references the rest of the set) and likewise return a working set anchor. Which is very convenient.

I suppose that this "DTO" might be an attempt at something similar where the List is the sole referenced object at the moment, but the "DTO" serves as an anchor object and thereby allows changes to the makeup of the working set to be done more easily, but I don't think that that literally qualifies as a DTO as defined in the design pattern.