为 2 个版本的数据模式设计 Web 界面

Question

我正在设计一个支持 2 个或更多版本的数据模式的 Web 界面。用 JAVA 表示的数据模式可能看起来像

PersonV1 {
  String fname
}

PersonV2 {
  String fname
  String lname
  String email
}

我预计将来会添加新版本。是否有任何关于如何根据 DRY 原则等构建此类 UI 的最佳实践。

关于这个的一点背景。我们有一个产品 A，对于这个产品的每个版本，我们可能有不同的架构。因此，每个实例版本我都会创建一个新模式。然后通过 jaxb 将该模式制成一堆 Java 对象并存储为库。每次有新版本的产品 A 时，都会重复此过程。

产品 B 将使用该库并从产品 A 获取 xml，因为我们知道它来自哪个版本，我们将能够填充正确的对象并将它们用作某种意义上的域对象用户界面。

谢谢

Answer 1

根据您的 Web 界面客户端的类型和多样性，您可以采用两种方式：

1. 将架构版本信息添加到路径或每个对象中。然后，每个客户端都必须将特定模式版本的对象转换为它可以使用的形式。对于比客户端软件更新的版本，最安全的方法可能是完全拒绝它。

2. 让客户端在其对服务器的请求中指明其首选/唯一接受的架构版本。然后由服务器将其当前架构转换为客户端请求的架构，或者失败并显示 400 表示请求的架构不被支持。

所以，假设您有一个只关心 fname 的 Web 客户端。在接收到 Person 时，无论模式版本如何，它都会提取 fname 并继续。

假设另一个网络客户端需要电子邮件地址。它将接受一个 v2 个人对象，但如果它返回一个 v1 个人，则通知用户服务器不兼容。

最后，假设 v3 将 fname 和 lname 替换为 name。在这种情况下，v2 可以通过附加 fname 和 lname 转换为 v3，也许 v3 可以通过在空间上拆分 name 转换为 v1，但是从 v1 到 v3 可能很难做一些有意义的事情。

显然会有很多情况，客户端或服务器必须放弃并简单地报告服务或客户端不兼容。但是，由于您是在从头开始设计服务时考虑到了变化，因此您希望在架构更改上投入更多的思考和谨慎。

有很多流行的文件格式标准都在与这类问题作斗争。例如，Zip 文件格式有多个修订版。生产者和消费者都必须有一个策略来处理特定版本的文件格式。 Java 二进制类格式是另一个例子。