在我开始描述我面临的问题之前，请允许我向您保证，我已经检查过是否已经有另一个线程讨论了这个问题。在大约5-6次尝试点击建议之后，我放弃了，因为很难从具有通用名称的线程中获得一个想法，例如“我可以使用什么样的设计模式？”
所以我把这个问题作为描述性标题提出来，因为我可以想出来。我之所以关注这个问题的原因是它感觉它应该是一个相当普遍的问题（当然其他人会在他们的客户端 - 服务器程序中遇到这个问题）。
=====
所以这是我的问题......
我有一台服务器S，还有几个客户端C1，C2，...，Cn。 客户可以在任何给定时间做三件事中的一件：
客户看到他们创建的事件的名称（并可能邀请其他客户），以及他们接受邀请的事件的名称。服务器处理所有邀请;当客户端邀请另一个客户端参加某个事件时，邀请会通过S但是S对事件E一无所知，而不是与其关联的名称，邀请客户端和受邀客户端。让我们将事件E的名称表示为| E |。
现在有两个事件Ea和Eb，| Ea | ！= | Eb |并不意味着Ea！= Eb。也就是说，仅仅因为两个事件具有不同的名称并不意味着它们是不同的。我不会在这里正式定义使两个事件相同的内容，但作为一个用例，假设它们具有相同的位置/时间，则两个事件是相同的。然而，服务器永远不会知道这个信息，只有客户端才知道，但是客户端之前可能无法很好地相互通信，因此可能会选择不同的名称来表示相同的（预期）事件。
我的问题：我想避免客户端Ca接受来自客户端Cb的邀请到事件Eb的情况，并且Cb接受来自Ca到Ea的邀请，其中Ea = Eb。这将导致每个客户看到两个| Ea |和| Eb |，实际上代表同一事件。
问题：如何避免上述情况？是否有可以单独在服务器上工作的设计模式，单独的客户端，或服务器和客户端一起工作？解决方案可以包括客户端的对话框/提示。
=====
此类客户端 - 服务器设置的实际实现可以是作为事件的讨论主题和作为客户端的员工。想象一下，克雷格和马特是很少见到对方的同事。他们突然意识到他们的老板要求他们调查为什么最近的软件升级不适合他们的一些客户。但是他们都不知道另一个人也被要求调查这个问题。因此，Craig创建了“讨论最近的升级”活动，Matt（比Craig做了更多的研究）怀疑它是一个（咳咳）Adobe问题，创建了“调查新的Adobe插件”。他们都互相邀请这些话题，都非常有礼貌，很容易接受。随之而来的是混乱。
答案 0 :(得分：0)
运行核心组件@ server的解决方案怎么样？ 我试图将此问题与标准调度问题进行映射，并通过更改通知冲突的约会和查找冲突逻辑。
此处服务器保留事件（或约会）列表。当发出新事件请求时，会进行冲突检查。如果发现冲突（可能是位置和时间，甚至是其他东西 - 用策略模式抽象）。服务器完全通过简单的外观模式隐藏了复杂性。
@Client方面可以对冲突进行编码，使对话框获得用户反馈以创建新事件或使用现有事件。
接下来的关键是，事件的存储方式和方式。这主要取决于用例。如果我们正在为具有以下数据的事件进行设计
Name, Date, Start time, Location, Organizer, Description
存储@服务器可以是典型的“基于Outlook的日历”方式或“事件列表@时间段”。