好吧，我过去使用过ServiceStack ORMLite，现在尝试使用ServiceStack RESTful DTO模式。我以前使用过WCF / Web API，对我来说，拥有不同方法的服务是一种自然的范例，你可以在需要的时候进行RPC调用。但是，在阅读有关Servicestack的DTO模式及其旗舰论点时：
当您使用远程界面（例如Remote Facade）时 （388），每次打电话都很贵。因此，您需要减少 通话次数，这意味着您需要转移更多 每次通话的数据。一种方法是使用大量参数。 然而，这通常很难编程 - 实际上，它经常是 Java等语言只能返回一个单独的语言 值。
解决方案是创建一个可以容纳所有数据的数据传输对象 通话数据。它需要可序列化才能跨越 连接。通常在服务器端使用汇编程序 在DTO和任何域对象之间传输数据。
这个论点本身对我提出了许多问题：
答案 0 :(得分：4)
Data Transfer Object pattern不是ServiceStack基于消息的服务受益的唯一模式，它还采用了相关的Remote Facade和Service Gateway模式，这是之前的答案describes benefits it gains by leveraging clean DTOs和文档列表Advantages of message-based Services。
这是否意味着当页面加载处理Product对象时，我们只需从Product表中提取所有数据
没有Coarse-grained接口不是要将整个Product数据集和缓存带到客户端上。您只返回对该上下文有用的数据，因此，如果您需要有关产品的信息，那么您将返回对客户有用的产品和相关元数据在查看产品时，例如类别/供应商信息，以防止客户端必须执行多个服务调用以获取所需的内容，从而减少延迟，减少需要维护/记录/学习的API表面区域，使相同的服务更可重用于不同的客户端用例单个缓存条目支持多个客户端，后端不太可能需要在UI更改时重写服务 - 而不是客户端特定的RPC调用。
如果一个电话的结果如何最终成为大量数据？
当您只需要摘要搜索结果时，不要删除完整数据集。优化搜索以仅返回需要在搜索结果上显示的数据。查看单个数据集时，您可以获取与产品相关的元数据。
如果我是一个糟糕的开发人员并且完全无视这项服务是为大量重用而设计的，并且每次需要任何数据时最终都会调用服务。那不是一把双刃剑吗？
当现有服务返回所需数据时，API消费者不太可能寻找不同的API来调用它们。拥有更少的粗粒度API调用自然会减少更容易缓存的调用，从而减少延迟，即使对于不知道如何构建高效并发API调用的天真开发人员也是如此。