Dapper 的“代码优先”指开发者自主定义实体类并手写SQL，不生成表或管理schema；它需配合FluentMigrator、DbUp等外部工具实现数据库迁移。
Dapper 本身不提供数据库迁移功能，它坚持“代码优先”（Code-First）的轻量实践，但这个“代码优先”和 Entity Framework 的 Code-First 不同——Dapper 不生成表、不管理 schema、不维护迁移历史。它的“代码优先”体现在：你用 C# 类定义数据结构，用 SQL 或动态查询直接操作数据库，所有逻辑由开发者掌控，没有 ORM 的自动映射干预。
什么是 Dapper 的“代码优先”
Dapper 的“代码优先”不是靠工具生成数据库，而是指：
- 你先写好实体类（POCO），它就是你的数据契约，无需特性或基类约束
- 你手写 SQL（或用 SqlBuilder 等辅助），SQL 结构决定查询结果如何映射到类
- 插入/更新时，你控制字段、参数、顺序，甚至可以跳过某些属性（比如忽略 Id 自增列）
- 没有隐式约定（如复数表名、下划线转 PascalCase），一切显式声明
Dapper 本身不支持迁移，但可以配合迁移工具
Dapper 是微 ORM，只负责对象与结果集之间的映射，不处理数据库结构变更。要实现类似 EF Migrations 的能力，你需要引入外部迁移方案：
- FluentMigrator：主流选择，基于 C# 编写迁移脚本，支持多数据库，可集成到 CI/CD
- DbUp：简单直接，按文件名顺序执行 SQL 脚本（.sql 文件），适合团队协作和版本控制
- Evolve：受 Flyway 启发，强调不可变迁移脚本和校验机制
- 自建轻量方案：用嵌入式资源 SQL + Dapper 执行，配合版本号表（如 SchemaVersion）手动追踪
一个典型配合 DbUp 的迁移流程
以 DbUp 为例，将迁移脚本与 Dapper 共存：
- 在项目中新建 /migrations 文件夹，放入 001_create_users_table.sql
- 启动时（如 Program.cs）调用 DbUp：检查当前 DB 版本 → 执行待运行脚本 → 更新版本表
- 业务层继续用 Dapper 查询：connection.Query<User>("SELECT * FROM Users")
- 实体类 User 和 SQL 字段保持一致即可，无需额外配置
为什么推荐“Dapper + 显式迁移”而非“全自动 Code-First”
这种组合更贴合真实项目需求：
- DBA 可审核每条建表/索引语句，避免 ORM 生成低效 SQL 或不兼容语法
- 遗留库或读写分离场景下，你只需为查询侧用 Dapper，迁移仍可独立管控
- 团队熟悉 SQL，不愿被抽象层限制；同时又不想每次改表都手动写 ADO.NET
- 测试更可控：迁移脚本可单独验证，Dapper 查询可针对内存 SQLite 快速跑单元测试
基本上就这些。Dapper 的定位很清晰：做好映射这一件事。数据库结构演进交给更专注的工具，各司其职，反而更稳更快。
