2

我目前正在将一个有点广泛的通信协议改造成更容易使用的东西，这是一个固执己见的问题，但根据您的经验，随着代码变得越来越大，这两个想法中的哪一个更容易维护。

有一个客户端和一个服务器。服务器具有客户端可能想要的信息，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

ETC

我倾向于使用第一个，因为它似乎使代码更易于阅读和使用，并且对组有特殊请求，例如 ABC，通常可以让服务器在其数据库上运行更少的查询来获得需要的信息。但是代码库将比现在大得多，而且由于我已经花时间彻底检查客户端和服务器的通信方式，所以我想听听这里的人们使用非此即彼方法的一些经验.

编辑：请注意，我不仅在谈论网络流量，还包括服务器将如何处理这些请求之类的事情。如果客户端发出三个单独的请求，服务器将不得不发出三个数据库查询，因为分组请求很可能作为单个查询运行。

4

3 回答 3

2

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

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

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

于 2012-04-26T20:35:22.467 回答
1

(2) 将更简单，但 (1) 效率更高且不那么复杂。我会选择（1）。它为您提供最佳的长期策略。

仔细想想，请求输入要么是 (2) 中的 T，要么是 (1) 中的 T[]。使用数组并不复杂。

于 2012-04-26T20:33:52.170 回答
0

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

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

于 2012-04-26T20:33:26.217 回答