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

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？
• 等

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

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