9

在您认为这是重复之前，请稍等片刻。当我研究 Web Api 关于版本控制的问题时，一切都关注版本控制控制器和在 url 与 headers 中指定版本的最佳实践。

我想弄清楚的是什么是版本输出响应的最佳方式，所以当我推出版本 2 时，我不会破坏版本 1 客户端。

假设我有一个不断变化的 DAL，用于为网站和其他服务提供服务的网站套件。我正在开发一个新的 Web Api 项目，该项目应该具有符合版本化模式的响应。

我的问题是，在经过版本控制的控制器和未版本控制的 DAL 之前，在 Web Api 项目中实施版本控制的行之有效的解决方案/最佳实践是什么？

我想出了一个解决方案，它涉及一个额外的版本化存储库层和一个额外的版本化模型层，因此版本化控制器使用使用版本化模型的版本化存储库。我已经设置 Automapper 在未版本化的域模型（来自 DAL）和版本化模型之间进行映射。但是这个设置的继承缺陷是，我必须为每个新版本更新所有地图；一个呈指数增长的问题。

一定有更好的方法。谢谢！

4

2 回答 2

2

根据我的经验，我们发现的最干净（但不是最简单）的解决方案分为 5 个部分：

  1. 拥有权威的数据模型和始终保持最新的后端：DAL/数据库/服务。
  2. 具有系统可以理解的特定于版本的数据：多数据模型。
  3. 确保正确识别和跟踪版本之间的更改，并且更改是可逆的。必须明确定义规则以处理该问题（这可能更难）：转换器。
  4. 让客户端明确告诉您他们使用哪个版本：查询字符串/标题。
  5. 拥有始终保持最新但知道如何在不同数据版本之间移动的权威业务逻辑 - 向后兼容：控制器。

例如，我们拥有的数据模型是供应商。

(1)后端（即 DAL/数据库）在 V5。业务逻辑（即服务）也在 V5 中。

(2)但是，我们需要同时为 V1、V2、V3、V4 上的客户供应商和 V5 上的最新客户提供服务。让我们将数据模型从 V1 到 V5：SupplierV1、SupplierV2...（您可以使用命名空间或其他方式来区分它们）

(3)您需要定义转换器并对其进行管理。它们必须处理数据模型版本之间的向前和向后兼容性。这可以通过策略模式、lambdas、具有 DI 转换器的管理器等来完成。您需要处理V1->V2->V3->V4->V5但还需要处理 V5- >V4->V3->V2 ->V1。

转换器中的规则是最难的部分。有时很容易 - 新字段的默认值。在其他时候，您需要运行一些业务逻辑。有时您需要转换/合并现有数据；你必须确保它是可逆的！例如，如果值在 V1 中是大小写混合的，而您在 V2 中将其转换为大写...您将无法将其恢复为 V1，因为您不知道哪些字符是大写和小写。您可以通过两种方式处理：

  • 对于 V1，保持大写。毕竟，只有 V2 需要它，V1 可能适用于所有大写字母（显然不适用于键）。
  • 将旧值保留在 V2 中的字段中。例如，如果您决定将 State 字段大写，您可以保留一个混合大小写的 OriginalState，并在返回 V1 时将其复制到 State。

如您所见，您需要认真考虑这些问题，而且这通常很重要。

(4)然后，在控制器中，您需要知道客户端使用哪个版本，以便在需要时进出控制器进行转换。为此，您可以使用查询字符串、标头（例如 X-API-Version 或 Accept，但要注意一些主机/代理会删除其中的一些）、post 参数等。

(5)最后，当控制器收到数据模型时，需要检查客户端发送的版本（比如说V2）并将其升级到后端的最新版本（V5）。然后正常使用，之后如果需要发回数据，需要降级到客户端版本（V2）。为此，您可以进行自定义绑定、自定义请求操作、自定义操作结果等。例如（请自动执行）：

public IHttpActionResult DoSomethingWithSupplier(JToken supplier) // Receiving Json Supplier
{
   // TODO: Get the client version type, for example in the X-API-Version header/query strings
   // (beware, some proxy/hosts strips some headers)
   // Type clientType = ...

   var clientSupplier = JsonConvert.DeserializeObject(supplier.ToString(), clientType);

   // You should probably detect latest version automatically (instead of typeof)
   var latestSupplier = VersionManager.Upgrade(clientSupplier, clientType, typeof(SupplierV5));

   outputSupplier = DoSomething(latestSupplier);

   // You should probably detect latest version automatically (instead of typeof)
   var clientOutputSupplier = VersionManager.Downgrade(outputSupplier, typeof(SupplierV5), clientType);

   return Ok(clientOutputSupplier);
}

这是向您展示这个想法的一种非常粗略的方式。这是我们在其中一个系统中所做的事情。您可以拥有检测类型和版本并自行处理转换的管理器，您可以使用依赖注入动态加载程序集/转换器，您可以在自定义绑定/请求操作中自动执行大部分转换，等等。

注意：您可能还需要考虑第(6)部分。要将数据库中的客户端数据实际更新到 V5，您可以在迁移到 V5（数据的批量迁移）时执行此操作，或者在运行时执行此操作。当您收到 SupplierV1 时，您从数据库中加载它（仍然是 V1 数据），升级到 V5，然后保存更新的数据，所有这些都在 Converter 中。这意味着您现在可以即时迁移后端。显然，这并不像听起来那么容易，因为您需要在同一个数据库中支持这两个版本，但根据您拥有的更改或数据的类型，它可能对您有用。

于 2014-01-10T18:08:43.267 回答
0

我建议对您的模型进行版本控制。您可以通过命名空间来做到这一点，以保持简单。事实上，NServiceBus 为它的消息传递做了类似的事情。这是他们的例子：http: //support.nservicebus.com/customer/portal/articles/894151-versioning-sample

于 2013-03-29T14:21:37.023 回答