简介这份资源面向正在学习或使用 Entity Framework 的 .NET 开发者重点演示 Code First「代码优先」模式在 SQLServer 与 MySQL 两种数据库下的完整落地方式。开发者只需编写领域模型数据类即可由 EF 自动生成数据库结构适合想对比不同数据库提供程序配置差异、掌握迁移与上下文初始化流程的中级读者。压缩包共 88 个文件约 13.61MB以 cs 源码、dll 程序集、config 配置、xml 文档、exe 可执行文件及 nupkg 包为主另含 csproj、sln 工程文件与少量脚本两个示例项目分别对应 SQLServer 与 MySQL 场景目录结构清晰便于直接运行调试。目前已有 706 人学习下载。通过该实例读者可获取两套可运行的 Code First 工程理解 MySql.Data.Entity 与 EntityFramework 的引用配置、连接字符串写法及模型映射差异并借助现成工程快速搭建自己的数据访问层减少环境配置与排错时间。1. 从一次数据库迁移翻车说起EF CodeFirst 双数据库实例到底能干什么去年帮一个朋友救火他们团队用 EF CodeFirst 开发了半年的项目一直跑在 SQL Server 上结果客户突然要求私有化部署到 MySQL。开发环境一切正常上了测试环境直接炸——迁移脚本报错、字段类型对不上、自增主键行为不一致三个人折腾了两天才勉强跑通。这个场景其实非常典型EF CodeFirst 在单数据库下用起来很爽一旦涉及 SQLServer 和 MySQL 双数据库切换坑就集中爆发了。这份 EF 代码优先实例资源核心就是解决这个问题。它提供了一套完整的 CodeFirst 工程结构同时包含 SQLServer 与 MySQL 两套 Provider 配置、迁移策略和初始化数据方案。适合正在用 EF 做多数据库适配的后端开发者也适合刚接触 CodeFirst 想找一个能直接跑起来的参考工程的人。下面我从工程结构开始拆把双数据库适配的每一步都落到可复现的操作上。2. 工程结构与双 Provider 配置先搞清楚代码怎么组织2.1 实体层、上下文层与配置层的职责划分拿到这个实例包第一件事不是急着跑迁移而是先看清目录结构。常见的组织方式是三层实体层Models、数据访问层Data、配置层Configurations。实体层只放 POCO 类不引用任何 EF 特定命名空间数据访问层放 DbContext 和迁移文件配置层用 Fluent API 或 Data Annotation 描述映射关系。为什么强调这个划分因为双数据库适配的第一原则是实体类必须保持数据库无关。一旦你在实体类上写了[Column(TypeName nvarchar(max))]这种 SQLServer 特有的标注切到 MySQL 就会出问题。我一般会把所有映射细节抽到EntityTypeConfigurationT里实体类保持干净。// Models/Product.cs —— 实体类保持纯净不引用 EF 命名空间 public class Product { public int Id { get; set; } public string Name { get; set; } public decimal Price { get; set; } public DateTime CreatedAt { get; set; } public bool IsActive { get; set; } }这个实体类没有任何 EF 或数据库相关的标注。Id默认会被识别为主键decimal和DateTime的类型映射交给配置层处理。这样做的好处是同一套实体可以同时被 SQLServer 和 MySQL 的 DbContext 使用不需要维护两份模型。2.2 用配置文件切换 SQLServer 与 MySQL Provider双数据库的核心在于 DbContext 的OnConfiguring方法或依赖注入时的 Provider 选择。实例包里通常会用配置文件appsettings.json来区分当前使用哪个数据库避免硬编码。// Data/AppDbContext.cs —— 根据配置动态选择 Provider public class AppDbContext : DbContext { public DbSetProduct Products { get; set; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { if (!optionsBuilder.IsConfigured) { var dbType ConfigurationManager.AppSettings[DbType]; var connStr ConfigurationManager.ConnectionStrings[dbType].ConnectionString; switch (dbType) { case SqlServer: optionsBuilder.UseSqlServer(connStr); break; case MySql: optionsBuilder.UseMySql(connStr, ServerVersion.AutoDetect(connStr)); break; default: throw new Exception($不支持的数据库类型: {dbType}); } } } }逻辑说明DbType从配置文件读取值为SqlServer或MySql。UseSqlServer和UseMySql分别来自Microsoft.EntityFrameworkCore.SqlServer和Pomelo.EntityFrameworkCore.MySql两个 NuGet 包。ServerVersion.AutoDetect会自动探测 MySQL 版本省去手动指定。参数说明连接字符串的格式两个数据库差异很大。SQLServer 典型格式是Serverlocalhost;DatabaseTestDb;Trusted_ConnectionTrue;MySQL 则是Serverlocalhost;Databasetestdb;Uidroot;Pwd123456;。实例包里一般会提供两个连接字符串模板改掉地址和密码就能用。注意Pomelo.EntityFrameworkCore.MySql是社区维护的 MySQL Provider版本要和 EF Core 主版本对齐。比如 EF Core 6.0 就配 Pomelo 6.0.x版本错位会报MethodNotFoundException。3. 迁移与初始化两套数据库怎么各跑各的迁移3.1 为不同 Provider 生成独立迁移文件EF CodeFirst 的迁移文件是跟 Provider 绑定的。SQLServer 生成的迁移脚本里会有nvarchar、IDENTITY这些关键字直接拿到 MySQL 上跑必然报错。正确做法是为每个 Provider 维护独立的迁移文件夹。# 为 SQLServer 生成迁移输出到 Migrations/SqlServer 目录 dotnet ef migrations add Init_SqlServer \ --context AppDbContext \ --output-dir Migrations/SqlServer # 为 MySQL 生成迁移输出到 Migrations/MySql 目录 dotnet ef migrations add Init_MySql \ --context AppDbContext \ --output-dir Migrations/MySql逻辑说明--output-dir参数把迁移文件按数据库类型分开存放。执行迁移时EF 会根据当前配置的 Provider 自动选择对应的迁移程序集。如果不分目录后生成的迁移会覆盖或混淆前一个导致dotnet ef database update时找不到匹配的迁移快照。参数说明--context指定 DbContext 类名如果项目里有多个上下文必须显式指定。--output-dir的路径是相对于项目根目录的。生成完两个迁移后Migrations文件夹下会有两个子目录各自包含_Snapshot.cs和迁移类文件。3.2 用 Seed 数据保证两套库初始状态一致迁移只建表结构初始化数据得靠HasData或自定义 Seed 方法。双数据库场景下Seed 数据必须用数据库无关的写法避免用原生 SQL。// Data/SeedData.cs —— 数据库无关的初始化数据 public static class SeedData { public static void Initialize(AppDbContext context) { context.Database.EnsureCreated(); if (context.Products.Any()) return; context.Products.AddRange( new Product { Name 基础版, Price 99.00m, CreatedAt DateTime.Now, IsActive true }, new Product { Name 专业版, Price 299.00m, CreatedAt DateTime.Now, IsActive true }, new Product { Name 企业版, Price 999.00m, CreatedAt DateTime.Now, IsActive false } ); context.SaveChanges(); } }逻辑说明EnsureCreated在数据库不存在时自动创建但注意它和迁移是互斥的——如果已经用dotnet ef database update跑过迁移就不要再调EnsureCreated否则会跳过迁移直接建表导致迁移历史表缺失。实例包里一般会在Program.cs或启动入口根据配置决定用哪种方式。参数说明Price用decimal类型SQLServer 默认映射为decimal(18,2)MySQL 默认映射为decimal(65,30)。如果业务对精度有要求需要在 Fluent API 里显式指定HasPrecision(18, 2)否则 MySQL 下会出现精度不一致的问题。这是双数据库适配里最容易忽略的一个坑。4. 避坑与排查双数据库适配中最容易翻车的五个点4.1 自增主键行为不一致导致插入失败现象SQLServer 下插入正常切到 MySQL 后报Field Id doesnt have a default value。原因SQLServer 的IDENTITY列和 MySQL 的AUTO_INCREMENT在 EF 里的默认约定不同。EF Core 对 int 主键默认按自增处理但如果 Fluent API 里写了ValueGeneratedNever()MySQL 就不会生成自增列。解决检查实体配置确保主键没有显式关闭值生成。如果需要手动指定主键值两个数据库都要用ValueGeneratedOnAdd()并在插入后重新查询。4.2 字符串类型长度限制差异现象SQLServer 下能存 500 字的字段MySQL 报Data too long for column。原因SQLServer 的nvarchar不指定长度时默认最大MySQL 的varchar必须指定长度不指定时 EF 默认给varchar(255)。解决在 Fluent API 里统一指定HasMaxLength或者对长文本用HasColumnType(text)。我一般会在配置层写一个扩展方法根据 Provider 动态返回类型名。4.3 迁移历史表名称冲突现象两个数据库用同一个__EFMigrationsHistory表名切换数据库后迁移状态混乱。原因EF 默认的迁移历史表名是固定的不会因为 Provider 不同而改变。解决在OnConfiguring里用optionsBuilder.UseSqlServer(connStr, x x.MigrationsHistoryTable(__SqlServerMigrations));分别指定不同的历史表名。这样两套迁移互不干扰。4.4 DateTime 精度与默认值差异现象MySQL 下DateTime字段插入时报Incorrect datetime value。原因MySQL 的datetime类型默认精度是秒而 .NET 的DateTime带毫秒。另外 MySQL 对0000-00-00这种默认值有严格模式限制。解决在 Fluent API 里用HasPrecision(6)指定毫秒精度或者把DateTime统一转成DateTimeOffset。实例包里一般会在配置层统一处理。4.5 事务隔离级别不同引发的并发问题现象SQLServer 下正常的并发插入MySQL 下出现死锁或重复键。原因SQLServer 默认隔离级别是READ COMMITTEDMySQL InnoDB 默认是REPEATABLE READ。同样的代码在两个数据库下的锁行为不同。解决在 DbContext 里显式设置隔离级别或者用乐观并发令牌RowVersion替代悲观锁。注意 MySQL 的RowVersion需要用timestamp类型SQLServer 用rowversion配置层要分开写。5. 进阶技巧用 Provider 感知的配置类统一管理差异5.1 写一个能识别当前数据库的配置扩展方法前面几个坑的根源都是「同一套配置代码要适配两个数据库」。最省事的做法是写一个扩展方法在OnModelCreating里根据当前 Provider 动态调整映射。// Data/ModelBuilderExtensions.cs —— Provider 感知的配置 public static class ModelBuilderExtensions { public static void ApplyProviderSpecificConfig(this ModelBuilder modelBuilder, DatabaseProvider provider) { foreach (var entityType in modelBuilder.Model.GetEntityTypes()) { foreach (var property in entityType.GetProperties()) { // 字符串类型MySQL 必须指定长度 if (property.ClrType typeof(string) provider DatabaseProvider.MySql) { if (property.GetMaxLength() null) property.SetMaxLength(255); } // decimal 精度统一为 18,2 if (property.ClrType typeof(decimal)) { property.SetPrecision(18); property.SetScale(2); } // DateTime 精度MySQL 需要显式指定 if (property.ClrType typeof(DateTime) provider DatabaseProvider.MySql) { property.SetPrecision(6); } } } } }逻辑说明遍历所有实体类型的所有属性根据当前 Provider 做针对性调整。字符串在 MySQL 下强制给默认长度decimal 统一精度DateTime 在 MySQL 下加毫秒精度。这样实体类和 Fluent API 配置都不用改切换数据库时自动适配。参数说明DatabaseProvider是一个自定义枚举值从配置文件读取。SetPrecision(18)和SetScale(2)对应 SQL 里的decimal(18,2)。SetPrecision(6)对 DateTime 表示保留 6 位毫秒。5.2 验证两套数据库行为是否一致的检查清单配置写完后怎么确认两个数据库跑出来的行为真的一样我一般会走一遍这个清单检查项SQLServer 预期MySQL 预期验证方式主键自增IDENTITY 从 1 开始AUTO_INCREMENT 从 1 开始插入三条记录看 Id字符串长度nvarchar 不限varchar(255)插入 300 字字符串decimal 精度decimal(18,2)decimal(18,2)插入 1.234 看存储值DateTime 毫秒保留 7 位保留 6 位插入带毫秒的时间迁移历史表__SqlServerMigrations__MySqlMigrations查表是否存在并发冲突报 DbUpdateConcurrencyException同样报错两个线程同时更新同一行这张表建议在每次修改实体或配置后都跑一遍。尤其是 decimal 精度和 DateTime 毫秒肉眼看不出来但业务层做金额计算或时间排序时就会暴露。5.3 一个我踩过的坑迁移文件不要手动改有次为了图省事直接在 SQLServer 的迁移文件里改了一个字段类型想着 MySQL 那边也手动改一下就行。结果下次dotnet ef migrations add时EF 对比快照发现不一致生成了一个空迁移把之前的修改全吞了。血泪经验迁移文件是自动生成的任何手动修改都会导致快照和实际结构脱节。正确做法是改实体或 Fluent API 配置然后重新生成迁移。从那以后我每次改完实体都强制走一遍「删迁移 → 重新生成 → 两个库各跑一次」的流程虽然麻烦但不会留下暗坑。希望帮到你。本文还有配套的精品资源点击获取