c# - Service Stack 的 DTO 模式真的有用吗？

Question

好吧，我过去使用过 ServiceStack ORMLite，现在尝试使用 ServiceStack RESTful DTO 模式。我过去使用过 WCF/Web API，对我来说，使用不同方法的服务是一种自然的范例，您只需在需要时进行 RPC 调用。然而，在阅读 Servicestack 的 DTO 模式及其旗舰参数时:

When you're working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program - indeed, it's often impossible with languages such as Java that return only a single value.

The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.

这个论点本身为我引出了很多问题:

1. 这是否意味着当加载处理 Product 对象的页面时，我们只需从 Product 表中提取所有数据并将其保留以供任何重复使用(潜在的重复使用)？
2. 如果一次调用 Get all 最终得到大量数据怎么办？我可以不争辩说，有时当一次调用中的“GetAll”带来大量不必要的数据时，然后在需要时返回服务器是一个更好的主意吗？
3. 此外，在我看来，该模式假设客户端开发人员将利用它作为 DTO 模式。该服务将被调用一次，返回的数据将在内存中保存很长时间以供进一步重用。如果我是一个糟糕的开发人员并且完全无视这个服务是为大量重用而设计的事实并且每次需要任何数据时最终都会调用服务怎么办？不就是两刃剑吗？

Answer 1

Data Transfer Object pattern这不是 ServiceStack 基于消息的服务受益的唯一模式，它还采用了相关的 Remote Facade和 Service Gateway模式，这个以前的答案 describes benefits it gains by leveraging clean DTOs和文档列表 Advantages of message-based Services .

Does it mean that when a page loads which deals with Product object then we just bring all the data from Product table

没有粗粒度接口(interface)并不是要将整个 Product 数据集和缓存都放在客户端上。您只会返回对该上下文有用的数据，因此如果您需要有关产品的信息，那么您将返回产品和相关元数据，这些元数据在查看产品时对客户有用，例如类别/供应商信息，以防止客户端必须执行多个服务调用来获取他们需要的东西，从而减少延迟，减少需要维护/记录/学习的 API 表面积，使相同的服务更可用于不同的客户端用例使用支持多个客户端的单个缓存条目，并且不太可能在 UI 更改时需要重写后端服务，而不是特定于客户端的 RPC 调用。

What if one call Get all ends up being a lot of data?

不，当您只需要摘要搜索结果时，不要使用完整的数据集。优化搜索以仅返回需要在搜索结果中显示的数据。查看单个数据集时，您可以获取与产品相关的元数据。

What if I am a bad developer and completely disregard the fact that this service is designed for a lot of re-use and ends up calling service every time any data is required. Wouldn't that be two edged sword?

API 使用者不太可能在现有服务返回所需数据时寻找不同的 API 进行调用。拥有更少的更粗粒度的 API 调用自然有助于减少更容易缓存的调用，即使对于不知道如何构建高效并发 API 调用的天真的开发人员来说，也能减少延迟。