ASP.NET Core 6.0 Web API版本化疑问：Program.cs依赖注入问题

尝试在ASP.NET Core 6.0 Web API中用Microsoft.AspNetCore.Mvc.Versioning实现版本化，期望按v1、v2独立文件夹存放对应版本控制器：

Controllers
 - v1
   - MyController
 - v2
   - MyController

但这种方式导致所有组件都要拆分V1.0和V2.0文件夹，包括模型的命名空间和类名：

namespace MyAPI.Models.V1 
{
     public class MyModelsV1 
     {
         // ...
     }
}

namespace MyAPI.Models.V2 
{
     public class MyModelsV2  
     {
         // ...
     }
}

进而在Program.cs的依赖注入环节出现问题，以Identity配置为例：
原本的配置是：

builder.Services.AddDefaultIdentity<AppUser>()
    .AddRoles<IdentityRole>()
    .AddClaimsPrincipalFactory<AppUserClaimsPrincipalFactory>()
    .AddDefaultTokenProviders()
    .AddEntityFrameworkStores<AppDbContext>();

现在出现了AppUserV1、AppUserV2，以及AppUserClaimsPrincipalFactoryV1、AppUserClaimsPrincipalFactoryV2，还有AppDbContextV1和AppDbContextV2。

疑问点：

• 当前方法是否有误？
• 是否需要为V1和V2分别构建独立服务：

builder.Services.AddDefaultIdentity<AppUserV1>()
 // ...
builder.Services.AddDefaultIdentity<AppUserV2>()
 // ...

• 如何在Program.cs中实现这种按v1.0、v2.0文件夹拆分的版本化方案？是否有完整的端到端实现方式？
• 是否应该采用其他版本化方案？

1. 当前方案的核心问题 #

你完全没必要把**Identity核心组件（如AppUser、AppDbContext）**也按版本拆分。API版本化的核心是隔离对外暴露的API接口和对应的请求/响应模型，而底层的领域模型、数据访问、身份认证核心逻辑应该保持复用，除非版本间有根本性的业务规则变更（比如用户表结构完全重构且无法兼容）。

2. 正确的版本化拆分范围 #

只需要拆分以下内容：

• 控制器：按v1、v2文件夹存放，控制器类上通过[ApiVersion("1.0")]、[ApiVersion("2.0")]标记，同时指定路由（比如[Route("api/v{version:apiVersion}/[controller]")]）
• 请求/响应模型：按V1、V2命名空间拆分（如MyAPI.Models.V1.MyModel、MyAPI.Models.V2.MyModel），用于适配不同版本API的参数和返回结构
• 若版本间有特定的业务逻辑差异，可以拆分对应的业务服务实现类，但底层依赖（如数据库上下文、用户实体）仍保持单一实例

3. Program.cs中的正确配置 #

不需要为不同版本重复注册Identity服务，保持原有单例配置即可：

builder.Services.AddDefaultIdentity<AppUser>()
    .AddRoles<IdentityRole>()
    .AddClaimsPrincipalFactory<AppUserClaimsPrincipalFactory>()
    .AddDefaultTokenProviders()
    .AddEntityFrameworkStores<AppDbContext>();

然后正确配置API版本化服务：

builder.Services.AddApiVersioning(options =>
{
    options.ReportApiVersions = true;
    options.AssumeDefaultVersionWhenUnspecified = true;
    options.DefaultApiVersion = new ApiVersion(1, 0);
    // 按控制器命名空间自动识别版本
    options.ApiVersionReader = new UrlSegmentApiVersionReader();
    options.Conventions.Add(new VersionByNamespaceConvention());
});

使用VersionByNamespaceConvention可以自动根据控制器所在的命名空间（如MyAPI.Controllers.V1）识别API版本，无需手动给每个控制器加[ApiVersion]标记。

4. 替代方案推荐 #

如果你的API版本间差异极大，甚至需要完全隔离底层服务，可以考虑以下方案：

• 独立项目部署：将v1和v2拆分为两个独立的ASP.NET Core Web API项目，各自拥有独立的依赖注入、数据库上下文等，这种方案适用于版本间完全不兼容的场景
• 条件分支逻辑：在同一个控制器中通过[MapToApiVersion]标记不同版本的Action，共享底层服务，只在Action中处理版本差异逻辑，这种方案适用于差异较小的版本迭代

5. 端到端实现步骤 #

1. 安装NuGet包：Microsoft.AspNetCore.Mvc.Versioning
2. 按文件夹结构组织控制器：

   Controllers
   ├─v1
   │  └─MyController.cs（命名空间：MyAPI.Controllers.V1）
   └─v2
      └─MyController.cs（命名空间：MyAPI.Controllers.V2）
   

3. 配置API版本化服务（如上述Program.cs代码）
4. 为不同版本的API创建对应的请求/响应模型，放在Models.V1、Models.V2命名空间下
5. 控制器中引用对应版本的模型，实现业务逻辑，底层服务（如Identity、数据访问）复用同一实例

内容的提问来源于stack exchange，提问作者Scottish Smile