Problems with column duplication when designing a Spring Restful DTO-CodePudding

I am learning about DTO recently. Among them, Request DTO can be created in various ways. As an example, we will take two examples of create and update related to User.

To create a user Let's say it takes name, sex, age, phoneNumber.

Then my UserCreateRequestDTO will be composed of a form that receives name, sex, age, phoneNumber as arguments.

@Getter
public class UserCreateRequestDTO {
    private String name;
    private String sex;
    private String age;
    private String phoneNumber;

    ... etc ()
}

Next, we'll edit the user's information. sex, age, phoneNumber without name Let's say you can edit it.

If so, my UserUpdateRequestDTO will be composed of receiving sex, age, and phoneNumber as arguments.

@Getter
public class UserUpdateRequestDTO {
    private String sex;
    private String age;
    private String phoneNumber;

    ... etc ()
}

So far, these two are using very similar fields.

Something is wrong, and it looks like you're writing unnecessary code.

If so, I have a question to summarize it or clear out the wrong part.

Is it bad to unify two similar requestDTOs and use them as one requestDTO? (One requestdto method handles all create and update information.)

@Getter
    public class UserRequestDTO {
        private String name;
        private String sex;
        private String age;
        private String phoneNumber;
        private String etc;

        ... etc
    }

Or is it bad to create one field model to share but create and update separately?

    @Getter
    public class UserCreateRequestDTO {
        private User user;

        ... etc
    }

    @Getter
    public class UserUpdateRequestDTO {
        private User user;

        ... etc
    }

    ////
    
    
    @Getter
    @Setter
    public class User {
        private String name;
        private String sex;
        private String age;
        private String phoneNumber;
    }

In other words, you want to know when you need to create more requestDTOs and if you can use them repeatedly.

CodePudding user response：

Based on my personal experience, I prefer crystal clear separated DTOs. It will make your life absolutely easier in future. Also it requires more duplicate and boring code, but at the end it can be easily tested, and maintained. It allows your interfaces/services to change independently.

As mentioned in https://medium.com/@schneidenbach/restful-api-best-practices-and-common-pitfalls-7a83ba3763b5

I like to keep things simple. Each controller (and sometimes endpoint, depending on the need) has its own DTO that it uses to process requests. My GETs will often return a subset of data and PUTs/POSTs are limited to updating only fields that I want to update. This makes it very clear and simple for you and your API consumers, while also enforcing a separation of concerns between your entities and your DTOs.

CodePudding user response：

Different DTO have different uses, and their names tell you what to do. For better maintenance and testing, you don't have to change one endpoint to affect another. I also hate copying DTO properties, but open source tools can alleviate these symptoms. Cheers！