从SQL Server迁移至PostgreSQL后EF6大小写适配方案咨询

针对EF6 Database First模式的适配能力说明 #

EF6 原生没有提供EF Core那种开箱即用的标识符大小写忽略匹配开关，但存在零侵入、不修改现有PascalCase实体命名的可行解决方案，按改造成本从低到高排序如下：

• 全局Fluent API映射配置（推荐）
  基于PostgreSQL的EF6 provider，在数据上下文的OnModelCreating生命周期中添加全局命名转译规则，自动将代码侧的PascalCase实体名、属性名转为全小写匹配PostgreSQL的库表结构，不需要修改任何现有实体类代码。核心配置代码如下：

  protected override void OnModelCreating(DbModelBuilder modelBuilder)
  {
      // 可根据原有SQL Server的命名规则选择是否移除默认复数表名约定
      // modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
      
      // 全局配置：所有实体映射到小写表名
      modelBuilder.Types().Configure(entity => entity.ToTable(entity.ClrType.Name.ToLower()));
      // 全局配置：所有属性映射到小写字段名
      modelBuilder.Properties().Configure(prop => prop.HasColumnName(prop.ClrPropertyInfo.Name.ToLower()));
  }
  

  如果原有SQL Server的表名采用帕斯卡命名+复数格式（如实体UserInfo对应表UserInfos），可以先调用系统自带的复数化服务转成复数格式再转小写即可，适配原有命名逻辑。
• EDMX映射批量修改
  如果项目完全依赖Database First生成的EDMX模型文件做映射，可以直接解析EDMX的XML结构，批量将存储模型层（SSDL）、映射层（MSL）中关联的表名、列名替换为全小写，不需要重新生成实体类，也不需要改动业务代码，适合EDMX自定义逻辑不多的项目。

不推荐通过给PostgreSQL的表、列加双引号强制使用帕斯卡命名的方案，该方案会让PostgreSQL进入严格大小写匹配模式，后续数据库运维、脚本编写的成本极高。

切换至Code First模式的实施难度评估 #

不存在完全无法适配Database First的场景，若出于架构规划考虑要切换到Code First，难度完全由项目规模决定：

• 小型项目（实体数量少于50，无复杂EF高级特性映射）：实施难度极低。现有PascalCase实体类可以直接复用，只需要新建Code First版本的DbContext，添加上述全局小写映射规则，补全必要的主键、外键配置即可，整体改造+基础验证耗时在1人天以内，业务层代码几乎不需要改动。
• 中大型项目（实体数量过百，包含存储过程映射、自定义函数映射、TPH/TPT继承映射、复杂多对多关系等逻辑）：实施难度中等。核心工作量是将原EDMX中配置的自定义映射规则迁移到Code First的Fluent API配置中，加上全量业务场景的回归测试，整体耗时通常在1~3人天，远低于重构实体命名的改造成本。

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