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 的场景下，有个轻量、透明、易测的数据访问基座。
