用 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 的参数化查询。关键点：
所有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 的场景下，有个轻量、透明、易测的数据访问基座。
