我正在读一本关于C＃中的响应消息模式的书中的一章，当我最近遇到一个使用Web API的项目时，我注意到了相似之处，并希望对某些内容有所了解。
在本书中，作者的代码在一个名为CustomerRequestService的类中包装请求（在本例中为CustomerRequest），其作用是处理这些请求（请求只不过是具有搜索条件等内容的类）或者与寻找客户的服务相关的属性，并且什么都不做非常薄/贫血（？）我想你可以说。该服务返回一个CustomerResponse，它包装一个客户类，来自服务器的响应，以及服务器端用于向用户显示结果的其他相关信息。
现在，在我正在查看的项目中，有一些网页可以对web api控制器进行ajax调用。控制器处理这些请求并以自己的响应进行响应。它使用json.net进行反序列化。
你可以说这非常相似。在本书中，作者称这些请求 - 响应，并在代码中，它们被命名为CustomerDto，CustomerResponseDto（当然DTO代表数据传输对象）。
当我在线搜索时，似乎在搜索webAPI时，命名标准围绕DTO而不是响应/请求。
也许我正在分裂头发，或者这是不可思议和无关紧要的，但在这样的场景中很奇怪其他人正在命名他们的请求/响应类。我喜欢调用所有请求/响应的想法，即使在web api架构中也是如此，但是我不确定这样做是不正确的，我应该称之为Dtos。
我猜的唯一区别是，有一件事是序列化的，并以JSON的形式发送回网页，而另一件事仍然是一个类。
如果我正确解释了这一点，请告诉我！
答案 0 :(得分：0)
你可以随心所欲地命名它们（一如既往地保持一致），但在这种情况下，使用DTO而不是Request / Response对我来说更有意义。 DTO用于以两种方式传输数据 - 从客户端到服务器，反之亦然。因此它在请求和响应中都使用。
答案 1 :(得分：0)
如果不创建单独的请求和响应对象，则最终会得到：
1。例如，转移整个DTO。由56列数据组成。
2。而您的需求是只绑定一个包含键值对的下拉列表，即只有两列。
或者，您可以理解，虽然仅需要5-7 kb的数据传输，但是您正在传输57 kb的数据，没有任何用处。这样，您只是浪费带宽，会对服务器和网络上的整个应用程序负载的性能产生不利影响。如果您优化了DTO来满足您的需求，那么您将获得超快速的应用程序，即使在最坏的情况下，该应用程序也可以加载2G连接。