Can DTO have helper method that operates on DTO fields?

Question

I wonder where to add method that reads my dto WindowDto.getPath().getPoints() and based on this collections returns some value (that value will be needed in some different srevices in my app):

public class WindowDto{

    @JsonProperty("valid_from")
    @JsonDeserialize(using = LocalDateDeserializer.class)
    private LocalDate validFrom;

    @JsonProperty("valid_to")
    @FutureOrPresent
    @JsonDeserialize(using = LocalDateDeserializer.class)
    private LocalDate validTo;

    @JsonProperty("type")
    private String type;

    @JsonProperty("path")
    @Valid
    private PathDto path;

    @Data
    public static class PathDto {
        @JsonProperty("points")
        private Set<PointDto> points;
    }

//maybe here my helper method
public Long getStoreId(){
//iterate over points and make some pure operations on this collection without using any repository etc...
}

Is it good practice to add such helper method in DTO? Or maybe create some other static class like WindowDtoHelper?

Answer 1

Do not get too hung up on DTOs being "property bags." When in doubt, fall back on good ol' fashioned Object-Oriented Programming. Classes bundle data and behavior. Your DTO needs some behavior. Add those methods to the class as long as you do not embed logic in the DTO that conceptually belongs in a different layer.

A DTO can have lots of null values. If you need to operate on a collection, and you pepper your code with a bunch of null-checks, adding a method to the DTO can help clean that up by centralizing the null-checks. Maybe worse case scenario you return an empty collection or Optional<T> from that method.

Answer 2

I disagree with Greg Burghardt. DTO stands for data transfer object. Not for data calculation object. If you want to calculate something inside your DTO, why not pass (or keep) this calculation in one additional field? (during construction)

In addition, I agree with what Victor Rentea said in Evolving a Clean, Pragmatic Architecture (also in youtube) about having public fields in DTO. He proposes public fields for the same reason I mentioned above. DTOs should be as dumb as it gets - just a bunch of properties in public fields.