将int类型主键改为自定义类是否合理？C#实体主键设计疑问

问题背景 #

常规实体主键多直接使用内置值类型：

public int Id { get; private set; }

而老师采用了自定义记录类型作为主键，并配套实现了值转换器与EF Core配置：

自定义主键类型 #

public record FuelstationId(int Value);

实体中的主键声明 #

public FuelstationId Id { get; set; } = default!;

值转换器实现 #

public class FuelstationIdValueConverter : ValueConverter<FuelstationId, int>
{
    public FuelstationIdValueConverter (ConverterMappingHints mappingHints = null!)
        : base(id => id.Value,
            value => new FuelstationId(value),
            mappingHints)
    { }
}

DbContext中配置映射 #

builder.Entity<Fuelstation>()
      .Property(f => f.Id)
      .HasConversion(new FuelstationIdValueConverter ())
      .HasColumnName("Id")
      .ValueGeneratedOnAdd()
      .IsRequired();

专业解答 #

这种做法属于**强类型主键（Strongly-Typed ID）**实践，在特定场景下非常值得推荐，但需要权衡其额外成本与收益：

核心优势 #

• 杜绝类型混淆：比如FuelstationId和UserId虽均基于int，但编译器会阻止将UserId误传入需要FuelstationId的方法，彻底避免"把用户ID当成加油站ID使用"这类低级bug，大型项目中能大幅减少隐患。
• 明确业务语义：自定义类型能直接传达主键的业务含义，比模糊的int Id更具可读性，看变量类型就能知道它对应哪个实体的标识。
• 降低重构成本：未来若需要将主键从int改为long或GUID，只需修改FuelstationId的内部实现与值转换器，无需在整个代码库中批量替换int类型。
• 支持业务规则验证：可在自定义类型中封装主键的合法性校验，比如确保ID值大于0，避免无效值流入业务逻辑：

  public record FuelstationId(int Value)
  {
      public static FuelstationId Create(int value)
      {
          if (value <= 0)
              throw new ArgumentOutOfRangeException(nameof(value), "加油站ID必须大于0");
          return new FuelstationId(value);
      }
  }
  

潜在劣势 #

• 增加代码冗余：需要额外定义主键类型、值转换器并配置EF Core映射，小型CRUD项目中这些代码属于不必要的负担。
• 有学习成本：团队若不熟悉EF Core值转换器机制，可能需要额外时间处理查询转换、迁移脚本生成等细节问题。
• 简单场景性价比低：无复杂业务逻辑的小型应用中，强类型主键的收益远低于代码维护成本，直接用int Id更高效。

适用场景推荐 #

优先选择这种方案的场景：

• 采用**领域驱动设计（DDD）**的大型项目，注重领域模型的精确性与语义表达。
• 项目中有多个实体使用相同内置类型作为主键（如多个实体用int ID），容易出现类型混淆的场景。
• 未来可能需要修改主键类型，或需要对主键值进行业务规则校验的场景。

如果是小型CRUD应用、快速原型开发，或团队对EF Core高级特性不熟悉，直接使用内置值类型的主键写法会更合适。

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