Dapper如何处理Guid类型 Dapper Guid参数和映射教程

Dapper不自动处理Guid与数据库字段的格式转换，需根据数据库类型适配：字符串存储用ToString("N")和char(36)，binary(16)需自定义TypeHandler，PostgreSQL推荐原生uuid类型并配合Npgsql驱动。

Dapper 本身不自动处理 Guid 类型与数据库字段的底层格式转换，具体怎么存、怎么读，取决于你数据库的字段类型（如 char(36)、uuid、binary(16)）以及你传参和映射时的写法。关键不是“Dapper 支持与否”，而是你是否做了适配——要么手动转字符串，要么用自定义 TypeHandler。

Guid 存成字符串（最常用，兼容性最强）

多数情况下，尤其是 PostgreSQL、SQLite 或老版本 SQL Server，数据库没有原生 uuid 类型，或你选择用字符串存储，这时推荐统一用 Guid.ToString("N")（32位无横线格式）存入 char(36) 或 varchar(36) 字段。

• 插入时：把 Guid 转成字符串再传参，例如 ID = Guid.NewGuid().ToString("N")
• 查询时：从字符串字段读出后，用 new Guid(reader.GetString("ID")) 或 Dapper 自动映射（只要属性是 Guid 类型，且值可解析）
• 建表建议：主键字段设为 char(36) NOT NULL PRIMARY KEY，比 varchar 更稳定（定长、索引友好）

Guid 映射到 binary(16)（空间更省，性能略优）

如果数据库支持 binary(16)（如 MySQL、SQL Server），且你希望节省存储、提升索引效率，可以把 Guid 存为 16 字节二进制。

• 存入前：用 guid.ToByteArray()
• 读出后：用 new Guid(byteArray)
• 但 Dapper 默认不识别 binary → Guid 的自动转换，必须注册自定义 ITypeHandler
• 示例处理器需重写 SetValue（写入时转 byte[]）和 Parse（读取时转 Guid）

PostgreSQL 的特殊处理（uuid 类型原生支持）

PostgreSQL 有内置 uuid 类型，推荐优先使用它而非字符串。

易标AI

告别低效手工，迎接AI标书新时代！3分钟智能生成，行业唯一具备查重功能，自动避雷废标项

135

查看详情

• 建表：ID uuid PRIMARY KEY DEFAULT gen_random_uuid()
• 插入时直接传 Guid 对象（Npgsql 驱动会自动处理），无需 ToString
• 查询结果也能自动映射到 C# 的 Guid 属性，前提是使用 Npgsql 连接器 + 正确配置
• 注意：不要用 varchar 或 text 存 uuid，否则失去类型语义和索引优化

避免踩坑的几个细节

Guid 映射看着简单，但容易在边界处出错：

• 实体类属性必须声明为 public Guid ID { get; set; }，不能是 string，否则 Dapper 不会尝试转换
• 参数化查询中，如果传的是 Guid 对象，而数据库字段是字符串，Npgsql/SqlClient 可能报类型不匹配——此时应显式转字符串
• Dapper Extensions 默认把 Id 属性为 Guid 的字段识别为主键，并设为 KeyType.Guid，但仅限于自动映射场景；手写 SQL 仍需自己控制格式
• 使用 QueryFirstOrDefault<t>()</t> 时，若数据库字段为空或 null，而 C# 属性是非 nullable Guid，会抛异常——建议用 Guid? 或提前判空

基本上就这些。核心就一条：数据库怎么存，代码就怎么转；Dapper 是桥梁，不是翻译官——它按你写的规则走，不猜意图。

以上就是Dapper如何处理Guid类型 Dapper Guid参数和映射教程的详细内容，更多请关注php中文网其它相关文章！