提供客户端 - 服务器向后兼容性的正确模式是什么？

Question

我正在开发一个客户端 - 服务器应用程序，并且不能强迫用户不使用旧版本的客户端，甚至其他客户端，因为该协议是WebDAV。

我需要的是支持所有这些，具有某种向后兼容性，以便服务器端的行为方式不同，具体取决于它使用的客户端版本。

我的问题是如何在面对这种情况之前准备我的应用程序。我需要使用一些设计模式吗？如何设计向后兼容性？

Answer 1

如果您为服务器创建了正确的API（Facade设计模式），那么您将来的生活将变得更轻松。

假设您的服务器提供的API由服务A，B和B组成。 C.这些服务在业务逻辑层中实现。从客户端访问这些服务总是通过外观，没有直接访问。所以你的门面（版本1）暴露了A，B和amp; C.到目前为止没什么大不了的......

现在假设您需要添加服务D，删除服务B并更改服务C.您创建了一个新的外观（版本2），它在您的业务层中公开服务A，D和更新的C.服务D的逻辑，标记B为“过时”，并且对于C的变化，它取决于变化是否向后兼容。如果是，那很容易，只需添加一个过载。如果服务C现在完全不同，则将其实现为新服务。有时虽然有变化打破了老客户......

Facade本身可以是一个Web服务（在大多数情况下是我首选的解决方案），并且没有自己的业务逻辑，它的唯一责任是将来自客户端的调用委托给适当的服务。

Answer 2

我认为你的棘手设计问题与设计模式的地址不同。

当然，您可以在核心业务逻辑之前应用Facade，公开不同的接口

MyServiceV1  { // the original interface

MyServiceV2  { // the new interface 

等等。我看到有趣的设计点来自于如何使用新实现实现旧接口。例如，假设在旧界面中有一个创建一些业务项的方法

createItem( String name,
            Integer value);

并且在新版本中

 createItem( String name,
            Integer value,
            String justification
 );

因此，当v1请求到达外观时，它将没有“理由”数据，那么外观应该做什么？可能会添加一些“未知”值，但您所做的不仅仅是设计问题，而是了解业务需求。显然，根据创建新版服务所做的不同变化，这类问题很多。

因此，首先通过界面了解界面，了解需求，处理不同的chnages的策略。这将导致各种实现问题，当您遇到这些问题时，您可能会开始看到实现中的模式，这些模式会促使您采用显式设计模式。

Answer 3

我认为在这种情况下使用的设计模式是strategy design pattern。

粗略......这个想法是：

• Server实例始终在侦听新连接。
• 当与Server建立新连接时，Server会创建一个ClientConnection实例来管理它。从该连接收到的所有后续数据都将路由到实例化的ClientConnection。
并由其处理
• 每个ClientConnection管理Server与单个远程客户端主机之间的所有通信。
• ClientConnection所做的第一件事是与远程客户端协商，并确定它是哪个版本。完成此操作后，ClientConnection将实例化ServerBehaviorStrategy的相应实现，以处理ClientConnection的所有后续通信。

这样，行为特定事物的所有编程都在ServerBehaviorStrategy接口的单独实现中完全隔离。