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

发布于 2024-10-14 08:07:13 字数 182 浏览 2 评论 0原文

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

清秋悲枫 2024-10-21 08:07:13

如果您为您的服务器创建一个合适的 API（Facade 设计模式），那么您的生活就会变得更加美好将来会更容易。

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

现在假设您需要添加服务 D、删除服务 B 并更改服务 C。您创建一个新的外观（版本 2），它公开服务 A、D 和更新的 C。你的业务层你会添加服务D的逻辑，将B标记为“过时”，至于C中的更改，则取决于更改是否向后兼容。如果是的话很简单，只需添加一个重载即可。如果服务 C 现在的工作方式完全不同，请将其实现为新服务。有时虽然有些变化会破坏旧客户端...

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

回复收藏 0 原文

待＂谢繁草 2024-10-21 08:07:13

我认为您棘手的设计问题与设计模式所解决的级别不同。

当然你可以在你的核心业务逻辑前面应用Facades，暴露不同的接口

MyServiceV1  { // the original interface

MyServiceV2  { // the new interface

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

createItem( String name,
            Integer value);

，而在新版本中您有

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

这样的方法，那么当 v1 请求到达外观时，它不会有用于“理由”的数据，那么外观应该做什么？可能添加一些“未知”的值，但您所做的与其说是设计问题，不如说是理解业务需求的问题。显然，根据创建新版本服务时所做的不同类型的更改，存在许多此类棘手的问题。

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

I think your tricky design problems are at a different level than Design Patterns address.

Of course you can apply Facades in front of your core business logic, exposing different interfaces

MyServiceV1  { // the original interface

MyServiceV2  { // the new interface

and so on. I see the interesting design points coming from how you implement the old interface with the new implementation. For example suppose in the old interface you have a method creating some business item

createItem( String name,
            Integer value);

and in the new version you have

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

So when a v1 request arrives at the facade it won't have data for "justification", so what should the facade do? Possibly add in some "UNKNOWN" value, but what you do is not so much a matter of design as a matter of understanding the business requirements. Clearly there are much tricker problems of this kind depending upon the different kinds of change made in creating the new version of the services.

So, first work through interface by interface understanding the requirements, the policies for dealing with the different chnages. This will lead to various implementation problems and when you get to those you may start to see patterns in the implementation that drive you to adopt explicit Design Patterns.

回复收藏 0 原文

壹場煙雨 2024-10-21 08:07:13

我认为在这种情况下使用的设计模式是策略设计模式。

大致...想法是：

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