通信协议的可维护性 - 重叠或个别请求？

Question

我目前正在将一个有点广泛的通信协议重新编写成更易于使用的内容，这是一个自以为是的问题，但根据您的经验，随着代码变大，这两个概念中的哪一个更易于维护更大。

有客户端和服务器。服务器具有客户端可能需要的信息，A，B，C，D等。一条信息不是一组数据，如名称，而是名称列表。通常是列的全部内容。客户通常会想要这些东西，如ABC，DEF，ABD等。没有重叠（意味着，通常80％的A请求也是对B和C的请求）。

随着系统变得越来越大，维护通信协议工作的系统就越容易：

Request 1: Server returns ABC
Request 2: Server returns ABD

或

Request 1: A
Request 2: B
Request 3: C

等

我倾向于使用第一个，因为它似乎使代码更容易阅读和使用，并且对ABC等群组的特殊请求通常可以让服务器运行更少的查询它的数据库来获取所需的信息。但是代码库将会比现在大得多，而且由于我已经花时间来彻底改变客户端和服务器的通信方式，我想听听人们在这里与之合作的一些经验。或方法。

编辑： 请注意，我不仅要讨论网络流量，还要讨论服务器如何处理这些请求。如果客户端发出三个单独的请求，则服务器必须进行三次数据库查询，其中分组请求很可能作为单个查询运行。

Answer 1

我认为这是“过早优化”的案例。

1. 您不知道实际上是否会出现性能问题。
2. 您所说的是感知性能问题的更复杂代码。
3. 实际上，第二个选项可能性能更糟（考虑哪个更重 - 接受连接并处理请求，或发出稍长的响应）？

现在，您更有可能发现任何瓶颈或性能问题可能与您查看此信息的位置（例如，在数据库中）有关。在这种情况下，您可以在不影响协议的情况下调整该端的性能（例如，您可以缓存数据库返回的值）。

Answer 2

（2）会更简单，但（1）效率更高，而不是那么复杂。我跟（1）一起去。它为您提供最佳的长期战略。

当你考虑它时，请求输入是（2）中的T in或（1）中的T []。使用数组并不复杂。

Answer 3

好吧，如果性能不是问题，你应该保留更简单的协议，它将提供你需要的一切，并使代码更小更整洁。

如果表现是一个问题 - 问题有多大？是否足以保证增加的复杂性？