执行命令后客户端应用程序应采取什么操作?

时间:2016-10-17 02:11:04

标签: java c# architecture client

背景

使用示例可以最好地说明这个问题。假设我有一个客户端应用程序(例如桌面应用程序,移动应用程序等),它使用来自Web服务的信息。其中一个屏幕具有一个产品列表,这些产品在客户端应用程序启动时从Web服务查询并绑定到UI元素。现在,用户创建了一个新产品。这会导致客户端应用程序向Web服务发送命令,以将该产品添加到数据库中。

问题

在客户端应用程序中,命令发出后会发生什么并且成功?你:

  1. 从服务中查询完整产品列表并刷新客户端应用程序中的整个产品列表?
  2. 只查询两个新添加的产品并将其添加到产品列表中?
  3. 不要查询,而只是使用客户端应用程序中的可用信息在GUI中创建新产品,然后将它们添加到列表中?
  4. 同样的问题也适用于更新。如果您更新产品,是否确认服务成功更新,然后让GUI更新产品而无需向服务提出进一步请求?

    修改 - 已添加其他详细信息

    从最初的反馈来看,外卖似乎采用最简单的方法,除非:

    1. 导致性能问题
    2. 对用户体验产生负面影响
    3. 我的应用程序中有一个主要/重要部分,与应用程序交互的主要方式是在多个不同的网格之间拖动网格记录。例如,将产品拖到另一个网格上会创建一个新订单,需要将其发送到服务。其中一些网格比标准网格更复杂。可以对记录进行分组,并且可以折叠/展开每个组(see here)。在这种情况下,虽然可以非常快速地从服务刷新网格,但这可能会导致可用性问题。使用所有新数据刷新网格时,如果用户有任何扩展/折叠组,则会丢失。

      因此,虽然我的应用程序中的大多数网格可能只是一次刷新,但更复杂的网格需要更仔细地更新。我认为这会借给选项1或2(至少用于创建新记录)。我有一个想法是客户端应用程序可以为要与应用程序一起发送的新记录创建GUID。这样,不需要对服务进行后续查询,因为客户端应用程序已经具有唯一ID。然后,客户端应用程序将在向用户显示新记录之前等待服务的成功响应。

2 个答案:

答案 0 :(得分:1)

我认为没有明确的正确答案;这些问题需要根据具体情况加以考虑。 #3本身通常不是一个选项 - 例如,如果您需要客户端拥有像ID一样的数据库生成的字段,它必须以某种方式从A点到达B点。你还需要考虑如何向用户揭露任何错误,因为如果你看起来一切都成功了,那就是糟糕的体验,但实际上你遇到了一个错误而产品并没有出现问题。真的很省。

除此之外,我将可用性视为我的下一个标准。如果刷新列表而不是仅添加几个产品,那么用户的体验会是什么样的?有显着差异吗?很大程度上取决于您的特定应用程序,以及正在完成的工作流程。如果添加产品是某人工作的主要部分,他们可能每天花费数小时来做这件事,那么即使只花一秒钟就可以为用户带来真正的胜利,而如果是这样的话。人们不时做的不常见的工作流程,性能预期会有所降低。

最后我会看一下代码维护和复杂性。如果两条路径提供相对类似的体验,请选择一个更容易构建和维护的路径。

还有其他选择。您可以使用混合方法 - 例如,可能在客户端上立即将数据添加到产品列表中(可能显示某种"保存"指示符),同时还异步查询数据库以便您可以刷新产品列表并报告任何错误。这种方法往往是最复杂的,但如果可用性需要它,你可能会走这条路。

答案 1 :(得分:1)

获取整个列表

我想这取决于请求/响应的成本。如果可能和有效,我总是会选择你的第一个选项(获取整个列表),直到出现性能问题。

As the saying goes

  
      
  • 程序优化的第一条规则:不要这样做。
  •   
  • 程序优化的第二条规则 - 仅限专家:不要这样做。
  •   

由于您无论如何都需要“获取整个列表”服务,因此可以覆盖的场景更少,编写的代码更少,维护的代码更少。 如果其他客户同时添加产品,它还会返回“最新产品列表”。

只有专业人士,直到出现性能问题,在我看来。这最后3个字意味着这个问题只会产生意见,应该被关闭......