客户端和服务器之间的数据应该有多大？

Question

“我有一个关于 DTO 以及 BE 和 FE 之间的数据交换的问题。

我们应该关心从 DB 调用或从 FE 传输并在 BE 接收的数据大小（之前发送到 FE 的数据，FE 请求重新发送以用于其他目的）？

或者在另一种情况下， 示例：我有一个函数需要聚合来自多个域对象的信息。其中一些信息将在一种上下文中使用，而其他信息将在另一种上下文中使用。我应该创建一个包含来自多个域对象的所有必要信息的 DTO 吗？为什么？

在需要一次发送所有内容的情况下，拆分 DTO 是否会在代码更干净、更易于维护方面更有效？”

谢谢。

我想问一下在性能和可维护性方面实现这一点的最佳方法。

Answer 1

欢迎来到SO。

此类决策没有严格的规则。通常人们设计独立且“精确”的 API - rach API 处理 1 个抽象。清晰度和可维护性优先于许多 http 请求。为了证明这一点，请检查任何公开 API 的产品。如果您一次准备好所有内容（就像一个巨大的 DTO），那么您有两个主要缺点：

1. 在其他用例中，您将不得不设计另一个巨大的 DTO。每个抽象的 API 更加灵活
2. 通常您不需要立即显示所有信息，您可以在页面之间导航、打开对话框等 - 每个操作都可能会显示一部分数据，通常客户端甚至看不到所有数据。这意味着您可能会在服务器上执行一些不必要的操作（查询数据库、计算等）来获取数据 - 因此浪费时间、服务器资源（CPU）和内存来分配巨大的 DAO。

另一个缺点与 UI 不太相关，但主要与后端相关：此方法不适用于微服务，在微服务中您可以在后台调用不同的服务来处理不同类型的信息。在巨大的 DTO 方法中，您应该有某种聪明的网关，可以将答案收集到一个或某个东西中......

因此，根据经验，您应该使用定义良好的细粒度 API，并将“巨型 DTO”（或换句话说“聚合 API”）方法视为未来的优化（这可能永远不会实现）。仅当您清楚地看到这是巨大的性能瓶颈时才去那里。 （根据我的经验）你永远不会在将 API 作为其业务一部分公开的产品中看到此类 API（例如 Github）。