设计 Spring Restful DTO 时列重复的问题
Problems with column duplication when designing a Spring Restful DTO
最近在学习DTO。
其中,Request DTO可以通过多种方式创建。
作为例子,我们举两个User相关的create和update的例子。
创建用户
假设它需要姓名、性别、年龄、电话号码。
然后我的 UserCreateRequestDTO 将由一个表单组成,该表单接收姓名、性别、年龄、电话号码作为参数。
@Getter
public class UserCreateRequestDTO {
private String name;
private String sex;
private String age;
private String phoneNumber;
... etc ()
}
接下来,我们将编辑用户信息。
没有姓名的性别、年龄、电话号码
假设您可以编辑它。
如果是这样,我的 UserUpdateRequestDTO 将由接收性别、年龄和电话号码作为参数组成。
@Getter
public class UserUpdateRequestDTO {
private String sex;
private String age;
private String phoneNumber;
... etc ()
}
到目前为止,这两个使用的字段非常相似。
出了点问题,您似乎在编写不必要的代码。
如果是这样,我有问题总结一下或者把错误的部分删掉
- 将两个相似的requestDTO统一起来作为一个requestDTO使用是不是不好?
(一个 requestdto 方法处理所有创建和更新信息。)
@Getter
public class UserRequestDTO {
private String name;
private String sex;
private String age;
private String phoneNumber;
private String etc;
... etc
}
- 或者创建一个字段模型来共享但单独创建和更新是不好的吗?
@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;
}
换句话说,您想知道何时需要创建更多的 requestDTO 以及是否可以重复使用它们。
根据我个人的经验,我更喜欢crystal清晰分离的DTO。
这将使您将来的生活绝对更轻松。它还需要更多重复和无聊的代码,但最终它可以很容易地测试和维护。它允许您的 interfaces/services 独立更改。
如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.
不同的DTO有不同的用途,看名字就知道该做什么。为了更好地维护和测试,您不必更改一个端点来影响另一个端点。我也讨厌复制 DTO 属性,但开源工具可以缓解这些症状。干杯!
最近在学习DTO。 其中,Request DTO可以通过多种方式创建。 作为例子,我们举两个User相关的create和update的例子。
创建用户 假设它需要姓名、性别、年龄、电话号码。
然后我的 UserCreateRequestDTO 将由一个表单组成,该表单接收姓名、性别、年龄、电话号码作为参数。
@Getter
public class UserCreateRequestDTO {
private String name;
private String sex;
private String age;
private String phoneNumber;
... etc ()
}
接下来,我们将编辑用户信息。 没有姓名的性别、年龄、电话号码 假设您可以编辑它。
如果是这样,我的 UserUpdateRequestDTO 将由接收性别、年龄和电话号码作为参数组成。
@Getter
public class UserUpdateRequestDTO {
private String sex;
private String age;
private String phoneNumber;
... etc ()
}
到目前为止,这两个使用的字段非常相似。
出了点问题,您似乎在编写不必要的代码。
如果是这样,我有问题总结一下或者把错误的部分删掉
- 将两个相似的requestDTO统一起来作为一个requestDTO使用是不是不好? (一个 requestdto 方法处理所有创建和更新信息。)
@Getter
public class UserRequestDTO {
private String name;
private String sex;
private String age;
private String phoneNumber;
private String etc;
... etc
}
- 或者创建一个字段模型来共享但单独创建和更新是不好的吗?
@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;
}
换句话说,您想知道何时需要创建更多的 requestDTO 以及是否可以重复使用它们。
根据我个人的经验,我更喜欢crystal清晰分离的DTO。 这将使您将来的生活绝对更轻松。它还需要更多重复和无聊的代码,但最终它可以很容易地测试和维护。它允许您的 interfaces/services 独立更改。
如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.
不同的DTO有不同的用途,看名字就知道该做什么。为了更好地维护和测试,您不必更改一个端点来影响另一个端点。我也讨厌复制 DTO 属性,但开源工具可以缓解这些症状。干杯!