客户端服务器设计问题：维护两者的状态答案

【问题标题】：Client Server Design Question: Maintaining State On Both客户端服务器设计问题：维护两者的状态
【发布时间】：2010-02-26 20:10:04
【问题描述】：

感谢您抽出宝贵时间查看我的问题！

让我们假设有一个 Web 服务（restful、SOAP、XML/JSON，任何你想要的），它是一个关于小狗的服务。就这个问题而言，小狗可以有两个成员变量。第一个是小狗的唯一 ID。另一个数据成员是“跳蚤数量”（Flea Count）。

小狗服务提供的功能之一可能是“根据小狗的 ID 返回代表小狗的对象”。

您将如何处理客户端应用程序可以更新 Flea Count 的要求？以下是我一直在想的一些想法：

谢谢。

【问题讨论】：

【解决方案1】：

取决于您的架构设计——确实没有一个正确的答案：

1) 这听起来像是使用“移动对象”，即整个对象（包括逻辑）可以序列化并通过网络发送。它也可以被视为没有逻辑的 DTO（数据传输对象）。

2) 这听起来更像 SOA——SOA 专注于使服务提供客户可以使用的直观方法。如果该方法被命名为 UpdatePuppyFleaCount(puppyId, fleaCount) 之类的名称，那么它是有意义的。

3) 这也是 SOA 的风格，但确实模糊了界限，因为它既是更新操作又是读取操作（如果您发送更新的 Puppy 对象并且服务器以提交的 Puppy 对象进行响应会更有意义——客户必须知道交换，但这并不少见）。

4) 这真的取决于用例。如果您希望更新跳蚤数量并且对小狗不做任何其他事情，那么这是有道理的。如果您希望在更新跳蚤数量后始终与小狗一起工作，那么要求客户端进行两次调用是一个糟糕的设计（网络服务调用很慢）。

5 - 4 的倒数（读取小狗，将小狗实例和新的跳蚤计数传递给服务器，取回更新的小狗）：同样，这更多地取决于用例。如果 Read 操作可能会与 UpdateFleaCount() 操作分开使用（即您并不总是希望在检索小狗后更新跳蚤计数），那么它很适合。

扩展我关于“没有一个正确答案”的评论......我创造了“银弹规则”（尽管我确信很久以前有人会打败我）在编程中从来没有银弹；您总是需要权衡不同方法的利弊、成本/收益。关键在于识别和理解不同方法之间的差异

【讨论】：

【解决方案2】：

puppy 的每个实例都在服务器上维护，服务应公开获取、设置和刷新puppycount 的方法。

【讨论】：

【解决方案3】：

数字 2，修改为返回一个布尔结果，指示更新成功或不成功

【讨论】：

【解决方案4】：

这里还有一些问题 (!)。

同一只小狗是否被多个客户持有？如果是这样，那么当有跳蚤更新时，您可能需要向每个客户端广播更新以刷新其小狗。

您通常会给客户一个不可变的对象（小狗）吗？客户端可以更新小狗并确保它仍然是有效的对象吗？这不是一个愚蠢的问题——客户端通常被赋予 DTO（数据传输对象）并且可以随意设置字段。适当的对象将确保有效性。

带宽重要吗？你能处理通过你的网络发布多只小狗吗？如果第一个问题的答案是“是”，这一点尤其重要。

鉴于上述情况，我可能会在服务器上调用一个方法，请求对小狗 X 进行跳蚤更新。服务器可以执行此操作（带有相关验证），并向所有感兴趣的各方发布更新。更新可能包含一个新的小狗对象（根据您的用例，您可能会发布小狗 X 已更新，如果有兴趣，客户可以获取新的小狗 - 也许这是一种过分的优化）

【讨论】：

不一定...最好有一个内置的状态跟踪方法，这样您就不必让客户端保持连接。如果有人有一只过时的小狗并且他们尝试更新它，那么您将不得不处理后果（通知用户，或者可能尝试聪明并确定更新是否冲突）。
虽然我不同意您的“更好”断言，但我认为可能会有不同的方法，具体取决于用例。相应修改。
很公平，但我认为需要保持从 web 服务到每个客户端以广播更新的连接将是少数……尤其是因为他是谈论使用 SOAP/XML/JSON。全部依赖 HTTP，HTTP 本质上是无状态的
@yoooder - 我没有在这里断言任何技术。只是可能需要更新多个客户端的可能要求。您如何选择这样做是另一个问题（HTTP 很可能不是答案）
另请注意，XML 和 JSON 是独立于传输的（SOAP 也是如此，但我承认除了 HTTP 之外我还没有看到过它）