.Net core 版本控制：文件夹结构/命名空间

Question

我正在尝试弄清楚 .Net core Web Api 2.0 中的版本控制，在看到很多“教程”后我有一些问题。

例如，我有一个包含很多控制器/模型/等的大型 API。

1. 创建新版本的最佳方式是什么？

• 我见过人们只是将所有控制器放在不同的文件夹/controllers/v1//controllers/v2/等中，模型也放在/models/v1/,models/v2等中。
• 我已经看到将所有控制器版本放在同一个文件中，并使用属性来指定哪个控制器属于哪个版本。（对我来说，这看起来很混乱，因为你无法追踪哪些有多个版本，哪些没有）。
• 我见过人们只是将几乎所有内容复制粘贴到新版本控制文件夹中：/v1/controllers, /v1/models、/v2/controllers, /v2/models。本质上，这只是将整个代码库克隆到一个新文件夹。（我喜欢这个，因为如果可以删除旧版本，您只需删除整个文件夹即可完成）。

2. 如何处理命名空间的变化？

例如，您有一个文件夹，其中 v1包含所有控制器、模型等。然后您想将所有内容复制到v2新版本。所有这些文件中的所有命名空间仍然包含.v1。如何将它们全部重命名为新的命名空间？

Answer 1

我发现上面提到的几乎所有方法都可以很好地发挥作用。但一如既往，这取决于很多因素。例如：

• 一段时间后是否有可能（在您的域中）停止支持以前的版本？
• 您对消费者有影响力吗？我的意思是你能强迫他们升级吗？
• 您能否将旧数据迁移到新数据（按需或通过单独的迁移步骤）
• 您可以将旧 API 使用者重新路由到新 API 吗？
• ETC。

这类问题可以帮助您确定哪个选项更可取。

例如，如果无法弃用以前的版本，因为 API 的外部使用者已经在维护中，并且没有简单的方法来迁移其数据并重新路由其请求，那么文件级分离将更适合您。v1/controller您在整个 API 级别 ( ) 或概念级别 ( )上执行此操作只是品味问题controller/v1。我个人更喜欢前者，因为这在代码组织方面提供了更多的灵活性。（它可以从一个版本演变到另一个版本）