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

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

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

定义泛型仓储接口

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

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

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

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

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

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

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

SQL 构建要安全且可控

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

所有 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 工厂委托更灵活：

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

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

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

# app # 数据访问 # sql # String # 封装 # 构造函数 # select # 字符串 # 接口 # Attribute # 委托 # Generic # 泛型 # var # delete # typeof # 异步 # table # 数据库 # 主键 # 又不 # 绑定 # 单条 # 这是 # 也不 # 有个 # 基座 # 分页 # 自定义

返回目录在线咨询

上一篇：微信小程序基础知识css样式media标签
下一篇：亚马逊云主机建站：应对突发流量高峰的最佳策略有哪些？

您的项目需求