.Net 核心版本控制：文件夾結構/命名空間

Question

我試圖弄清楚.Net core Web Api 2.0 的版本控制，在看到很多“教程”后我有一些問題。

例如，我有一個帶有很多控制器/模型/等的大型 api。

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

• 我見過人們只是將所有控制器放在不同的文件夾/controllers/v1/ / controllers/v2/等中，而模型也在/models/v1/ 、 models/v2等中。
• 我已經看到將所有 controller 版本放在同一個文件中，並使用屬性來指定哪個 controller 屬於哪個版本。 （對我來說，這看起來很亂，因為您忘記了哪些有多個版本，哪些沒有）。
• 我看到人們只是將幾乎所有內容復制粘貼到新的版本控制文件夾中： /v1/controllers, /v1/models 、 /v2/controllers, /v2/models 。 本質上只是將整個代碼庫克隆到一個新文件夾。 （我喜歡這個，因為如果可以刪除舊版本，您只需刪除整個文件夾即可）。

2.你如何處理命名空間的變化？

例如，您有一個包含v1的文件夾，其中包含所有控制器、模型等。然后您想將所有內容復制到v2以獲取新版本。 所有這些文件中的所有命名空間仍然包含.v1 。 如何將它們全部重命名為新的命名空間？

Answer 1

我已經看到幾乎所有上述方法都可以很好地工作。 但與往常一樣，這取決於很多因素。 例如：

• 是否有可能（在您的域中）在一段時間后停止支持以前的版本？
• 你對你的消費者有影響嗎？ 我的意思是你能強迫他們升級嗎？
• 您能否將舊數據遷移到新數據（按需或通過單獨的遷移步驟）
• 您能否將舊的 API 消費者重新路由到新的 API？
• 等等

這類問題可以幫助您確定哪個選項更可取。

例如，如果以前的版本不能被棄用，因為 API 的外部使用者已經在維護中，並且沒有簡單的方法來遷移他們的數據並重新路由他們的請求，那么文件級別分離將更適合您。 您在整個 API 級別 ( v1/controller ) 或概念級別 ( controller/v1 ) 上執行此操作只是口味問題。 我個人更喜歡前者，因為這在代碼組織方面提供了更多的靈活性。 （它可以從一個版本發展到另一個版本）