客户端应用程序在执行命令后应该采取什么行动？
What action should a client application take after executing a command?
背景
这个问题最好用一个例子来说明。假设我有一个客户端应用程序（例如桌面应用程序、移动应用程序等），它使用来自 Web 服务的信息。其中一个屏幕有一个产品列表，这些产品在客户端应用程序启动时从 Web 服务中查询并绑定到 UI 元素。现在，用户创建了一个新产品。这会导致客户端应用程序向 Web 服务发送命令以将该产品添加到数据库。
问题
在客户端应用程序中，发出命令并成功后会发生什么？你：
- 从服务中查询完整的产品列表并在客户端应用程序中刷新整个产品列表？
- 只查询两个新添加的产品并将其添加到产品列表中？
- 不要查询，而只是使用客户端应用程序中可用的信息在 GUI 中创建新产品，然后将它们添加到列表中？
同样的问题也适用于更新。如果您更新产品，是否会收到服务更新成功的确认信息，然后让 GUI 更新产品而无需进一步请求服务？
编辑 - 添加了更多详细信息
从最初的反馈来看，要点似乎是采用最简单的方法，除非：
- 导致性能问题
- 对用户体验产生负面影响
我的应用程序有一个 major/significant 部分，其中与应用程序交互的主要方式是在多个不同的网格之间拖动网格记录。例如，将产品拖到另一个网格上会创建一个新订单，需要将其发送到服务。其中一些网格比标准网格更复杂。记录可以分组，每组可以collapsed/expanded（see here）。在这种情况下，虽然可以非常快速地从服务刷新网格，但这可能会导致可用性问题。当用所有新数据刷新网格时，如果用户有任何组 expanded/collapsed，这将丢失。
因此，虽然我的应用程序中的大多数网格可能都可以一次全部刷新，但更复杂的网格需要更仔细地更新。我认为这会借给选项 1 或 2（至少用于创建新记录）。我的一个想法是，客户端应用程序可以为要随应用程序发送的新记录创建 GUID。这样，就不需要对服务进行后续查询，因为客户端应用程序已经具有唯一 ID。然后，客户端应用程序将等待服务的成功响应，然后再向用户显示新记录。
我不认为有任何明确的正确答案；这些问题需要根据具体情况来考虑。 #3 本身通常不是一个选项 - 例如，如果您需要客户端具有数据库生成的字段（如 ID），则它必须以某种方式从 A 点到达 B 点。您还需要考虑如何向用户暴露任何错误，因为如果您让一切看起来都成功了，但实际上您有错误并且产品没有真正保存，那将是一种糟糕的体验。
除此之外，我会将可用性视为我的下一个标准。如果您刷新列表而不是只添加几个产品，您的用户会有什么体验？有显着差异吗？很多都取决于您的特定应用程序，以及正在完成的工作流程。如果添加产品是某人工作的主要部分，他们可能每天要花几个小时做这件事，那么即使节省一秒钟的时间对您的用户来说也是真正的胜利，而如果这是人们经常做的不常见的工作流程到时候，性能预期有点低。
最后我会看看代码维护和复杂性。如果两条路径提供的体验相对相似，请选择更易于构建和维护的路径。
还有其他选择。您可以采用混合方法 - 例如，您可以在客户端上立即将数据添加到产品列表（可能显示某种 "saving" 指示器），同时异步查询数据库以便刷新产品列出并报告任何错误。这种方法往往是最复杂的，但如果可用性需要，您可能会采用这种方法。
获取整个列表
我想这取决于 request/response 的价格。如果可能且高效，我将始终选择您的第一个选项（获取整个列表），直到出现性能问题。
- The First Rule of Program Optimization: Don't do it.
- The Second Rule of Program Optimization – For experts only: Don't do it yet.
要涵盖的场景更少，要编写的代码更少，要维护的代码更少，因为无论如何您都需要“获取整个列表”服务。
它还 returns“最新的产品列表”，以防其他客户同时添加产品。
只有专家，直到出现性能问题，在我看来。这最后 3 个词意味着这个问题只会导致意见，应该关闭...
背景
这个问题最好用一个例子来说明。假设我有一个客户端应用程序（例如桌面应用程序、移动应用程序等），它使用来自 Web 服务的信息。其中一个屏幕有一个产品列表，这些产品在客户端应用程序启动时从 Web 服务中查询并绑定到 UI 元素。现在，用户创建了一个新产品。这会导致客户端应用程序向 Web 服务发送命令以将该产品添加到数据库。
问题
在客户端应用程序中，发出命令并成功后会发生什么？你：
- 从服务中查询完整的产品列表并在客户端应用程序中刷新整个产品列表？
- 只查询两个新添加的产品并将其添加到产品列表中？
- 不要查询，而只是使用客户端应用程序中可用的信息在 GUI 中创建新产品，然后将它们添加到列表中？
同样的问题也适用于更新。如果您更新产品，是否会收到服务更新成功的确认信息，然后让 GUI 更新产品而无需进一步请求服务？
编辑 - 添加了更多详细信息
从最初的反馈来看，要点似乎是采用最简单的方法，除非：
- 导致性能问题
- 对用户体验产生负面影响
我的应用程序有一个 major/significant 部分，其中与应用程序交互的主要方式是在多个不同的网格之间拖动网格记录。例如，将产品拖到另一个网格上会创建一个新订单，需要将其发送到服务。其中一些网格比标准网格更复杂。记录可以分组，每组可以collapsed/expanded（see here）。在这种情况下，虽然可以非常快速地从服务刷新网格，但这可能会导致可用性问题。当用所有新数据刷新网格时，如果用户有任何组 expanded/collapsed，这将丢失。
因此，虽然我的应用程序中的大多数网格可能都可以一次全部刷新，但更复杂的网格需要更仔细地更新。我认为这会借给选项 1 或 2（至少用于创建新记录）。我的一个想法是，客户端应用程序可以为要随应用程序发送的新记录创建 GUID。这样，就不需要对服务进行后续查询，因为客户端应用程序已经具有唯一 ID。然后，客户端应用程序将等待服务的成功响应，然后再向用户显示新记录。
我不认为有任何明确的正确答案；这些问题需要根据具体情况来考虑。 #3 本身通常不是一个选项 - 例如，如果您需要客户端具有数据库生成的字段（如 ID），则它必须以某种方式从 A 点到达 B 点。您还需要考虑如何向用户暴露任何错误，因为如果您让一切看起来都成功了，但实际上您有错误并且产品没有真正保存，那将是一种糟糕的体验。
除此之外，我会将可用性视为我的下一个标准。如果您刷新列表而不是只添加几个产品，您的用户会有什么体验？有显着差异吗？很多都取决于您的特定应用程序，以及正在完成的工作流程。如果添加产品是某人工作的主要部分，他们可能每天要花几个小时做这件事，那么即使节省一秒钟的时间对您的用户来说也是真正的胜利，而如果这是人们经常做的不常见的工作流程到时候，性能预期有点低。
最后我会看看代码维护和复杂性。如果两条路径提供的体验相对相似，请选择更易于构建和维护的路径。
还有其他选择。您可以采用混合方法 - 例如，您可以在客户端上立即将数据添加到产品列表（可能显示某种 "saving" 指示器），同时异步查询数据库以便刷新产品列出并报告任何错误。这种方法往往是最复杂的，但如果可用性需要，您可能会采用这种方法。
获取整个列表
我想这取决于 request/response 的价格。如果可能且高效，我将始终选择您的第一个选项（获取整个列表），直到出现性能问题。
- The First Rule of Program Optimization: Don't do it.
- The Second Rule of Program Optimization – For experts only: Don't do it yet.
要涵盖的场景更少，要编写的代码更少，要维护的代码更少，因为无论如何您都需要“获取整个列表”服务。 它还 returns“最新的产品列表”，以防其他客户同时添加产品。
只有专家，直到出现性能问题，在我看来。这最后 3 个词意味着这个问题只会导致意见，应该关闭...