Dapper怎么实现仓储模式泛型封装 Dapper Generic Repository指南

Dapper泛型仓储是借其轻量SQL能力补足统一数据访问抽象，核心为定义IRepository接口、约定/特性推导表名主键、参数化SQL构建、连接事务交由上层管理。

用 Dapper 实现泛型仓储（Generic Repository）不是给 Dapper “套壳”，而是借它轻量高效的 SQL 执行能力，补足自身缺少的统一数据访问抽象。核心思路是：定义通用接口约束操作范围，用泛型类型参数绑定实体与主键，再通过表达式或约定推导表名、主键列名，最后用 Dapper 的 Query、Execute 等方法完成实际数据库交互。

定义泛型仓储接口

先明确契约，避免过度设计。一个实用的 IRepository<tentity tkey></tentity> 通常包含增删改查基本操作：

• GetById：按主键查单条（支持异步）
• GetAll：查全部（可带排序、分页参数）
• Insert：插入单条，返回新主键（如自增 ID）
• Update：按主键更新，建议只更新非主键字段
• Delete：按主键删除

接口不暴露 Connection 或 Transaction，把数据访问细节留给实现类处理。

实现类中处理表名与主键推导

Dapper 本身不约定 ORM 映射，所以得自己解决“实体类 → 表名”、“实体属性 → 主键列”的映射问题。常见做法有三种：

• 约定优于配置：默认表名 = 类名复数（如 User → Users），主键属性名 = Id 或 XXXId
• 特性标记：用自定义 Attribute（如 [Table("sys_user")]、[Key]）显式声明
• 配置字典：启动时注册映射关系，适合遗留系统或复杂别名场景

推荐从约定起步，配合特性兜底。例如用 typeof(TEntity).GetCustomAttributes<tableattribute>()</tableattribute> 优先读取特性，没找到再走默认复数规则。

SQL 构建要安全且可控

泛型仓储里不能拼接 SQL 字符串，必须用 Dapper 的参数化查询。关键点：

Google Antigravity

谷歌推出的AI原生IDE，AI智能体协作开发

277

查看详情

• 所有 WHERE 条件、ORDER BY 字段、INSERT INTO 列名都应基于反射或表达式树生成，而非字符串拼接
• 主键更新/删除语句中，WHERE Id = @id 的 @id 必须和传入的 TKey 参数严格对应
• 插入时用 DynamicParameters 过滤掉主键字段（如自增 ID），避免冲突

例如 Update 方法内可这样写：
var props = typeof(TEntity).GetProperties().Where(p => p.Name != "Id");
var setSql = string.Join(", ", props.Select(p => $"{p.Name} = @{p.Name}"));
conn.Execute($"UPDATE {tableName} SET {setSql} WHERE Id = @Id", entity);

事务与连接生命周期交给上层

泛型仓储本身不管理 IDbConnection 的创建和释放，也不开启事务——这是应用服务层或工作单元（Unit of Work）的责任。仓储构造函数接收 IDbConnection 或 Func<idbconnection></idbconnection> 工厂委托更灵活：

• 测试时可注入 MockConnection
• Web 请求中可绑定到当前 HttpContext 的共享连接
• 需事务时由调用方传入已开启事务的 connection

这样既保持仓储纯净，又不牺牲可控性。

基本上就这些。Dapper 的泛型仓储不是为了替代 EF，而是让你在需要精细控制 SQL、又不想重复写 CRUD 的场景下，有个轻量、透明、易测的数据访问基座。

以上就是Dapper怎么实现仓储模式泛型封装 Dapper Generic Repository指南的详细内容，更多请关注php中文网其它相关文章！