【发布时间】：2018-06-12 11:39:54
【问题描述】：
我正在设计一个安静的 Web 服务，我想知道我应该如何命名我的 DTO。我可以为它们使用诸如请求和响应之类的后缀吗？例如对于 addUser 服务，将有 2 个 DTO，分别命名为：AddUserRequest 和 AddUserResponse。
【问题讨论】：
标签： oop design-patterns naming-conventions design-principles
【发布时间】：2018-06-12 11:39:54
【问题描述】：
您的组织是否已有描述您传入的规范用户的架构？如果这就是您正在使用的，那么您当然会使用该架构中的名称。否则，就像描述任何类或模式元素一样描述它们。
请注意，由于 DTO 不包含自己的方法，因此您可能不会给它起一个带有动作动词的名称。
但是，请考虑将它们称为 AddUserRequest 和 AddUserResponse，尤其是当该方法需要的信息不仅仅是您的常规用户 DTO 时。这符合接口隔离原则，因为您的接口参数应该专门针对请求本身进行定制（它不应该需要与请求无关的元素；并且您不应该有改变请求的函数类型参数，那些应该被提取到他们自己的调用中。）然后 AddUserRequest 可能包含一个名为 User 的元素，它保存用户特定的数据，另一个元素保存请求中的其他相关数据集，可能是组或访问权限，诸如此类.
【讨论】：
DTO（数据传输对象）类似于 POJO（普通旧 Java 对象）。它应该只有getters 和setters 而没有任何业务逻辑。
来自维基百科：
数据传输对象是在之间传输数据的对象 过程。使用它的动机是 流程通常通过远程接口（例如，Web services），其中每次调用都是昂贵的操作。因为 每次通话的大部分费用都与往返时间有关 在客户端和服务器之间，一种减少数量的方法 调用是使用一个对象（DTO）来聚合数据 会被几个电话转移，但这是服务的 只需一个电话。
数据传输对象和业务对象的区别或 数据访问对象是 DTO 没有任何行为，除了 用于存储和检索自己的数据（修改器和访问器）。 DTO 是不应该包含任何业务逻辑的简单对象 这需要测试。
这种模式在远程接口之外经常被错误地使用。 这引发了作者[3]的回应，他重申 DTO 的全部目的是在昂贵的远程传输数据 来电。
因此，理想情况下，您应该为这些操作创建一些帮助程序，或者您可以将它们添加为控制器。
【讨论】：
由于它是一个 RESTful 服务，理想情况下，用户添加/创建请求应该发回 201 created HTTP 状态代码，userId 在位置标头中，没有响应正文。对于请求，您可以将其命名为 UserDetails 或 UserData 或简称为 User。参考https://pontus.ullgren.com/view/Return_Location_header_after_resource_creation
【讨论】：