0

我正在研究 .Net Core 3.1 上的 API 版本控制。问题是我们正在使用一个外部 nuget 包，它将在不同的 API 版本上应用不同的版本。例如，对于 API 版本 1.0，我需要使用这个 nuget 包的 V2.0；对于 API 版本 2.0，我需要使用这个 nuget 包的 V3.0。

因此，如果我以这种方式使用该策略：https://dev.to/99darshan/restful-web-api-versioning-with-asp-net-core-1e8g通过在同一个项目中拆分控制器类，那么它将强制我所有的 API 版本都具有相同的 nuget 包版本。

我想知道在我的场景中进行 API 版本控制的更好方法是什么？

4

1 回答 1

0

只要您使用的功能在功能上兼容（通常通过源代码），NuGet 包版本就不需要匹配。您没有具体说，但我得到的印象是您通过应用属性来定义 API 版本，这是定义相应控制器的代码和库使用的唯一表面区域。

您正在描述基于插件或组合的 API 应用程序的典型设置。假设这是正确的，那么 NuGet 包版本只对宿主应用程序（例如宿主服务器代码）感兴趣。运行服务器的宿主应用程序必须使用高于或等于任何其他引用程序集使用的最高版本的 NuGet 包版本。其余的由 .NET 处理，而不是 NuGet。现代 .NET 项目支持自动绑定重定向；通常没有任何开发人员配置。这意味着如果您的控制器库是一组说版本1.0、2.0和3.0主机引用3.0，那么所有库最终都使用3.0在运行时。唯一需要注意的是，所有库都必须针对相同的运行时。例如，您不能将完整的 .NET Framework 和 .NET 5.0（以前的 .NET Core）混合在一起工作。只要运行时是对齐的，那么对齐所有内容应该没有任何问题；无论是 NuGet 包还是程序集版本。

对于这个问题，至少还有另外两种解决方案。

  1. 使用约定——API 版本控制为按约定定义 API 版本提供了流畅的接口。它旨在解决将 API 版本元数据应用于另一个库中定义的控制器的确切问题。此配置可能会在主机应用程序中定义。您还可以定义您的约定，这样您就不必单独定义每个版本。使用VersionByNamespaceConvention此方法通过包含的 .NET 命名空间派生单个 API 版本。
  2. 使用自定义元数据- 与流行的看法相反，API 版本控制不关心属性。它提供了一些属性，作为一种简单的、开箱即用的方式来应用元数据，但这不是硬性要求。它只关心IApiVersionProvider. 这意味着您可以轻松滚动自己的属性，然后通过实现IApiVersionProvider或将其插入 API 版本控制中IControllerConvention。这将允许您创建元数据库，如有必要，使用 .NET Standard，这可能永远不会改变，您随后可以添加到版本控制配置。

#2 是一个更高级的场景。我不知道有任何现有的例子可以证明所有这些端到端，但如果你选择了这条路并且有问题，我可以把你推向正确的方向。

于 2021-02-23T19:05:55.043 回答