Dapper通用仓储应借鉴EF思想而非照搬，核心是泛型约束+手写SQL灵活性：定义IRepository<T>接口（GetById/Find/Insert/Update/Delete），实现类通过特性识别主键与列映射，动态生成安全SQL，支持事务参数，分页由具体方法处理，查询逻辑下沉至具体仓储，连接由DI管理。
用 Dapper 实现通用仓储（Generic Repository）不是要完全照搬 Entity Framework 那套抽象，而是借其思想——统一数据访问入口、减少重复 SQL、提升可测试性与可维护性。核心在于：用泛型约束实体类型，用 Dapper 的轻量扩展能力封装增删改查共性逻辑，同时保留手写 SQL 的灵活性和性能优势。
定义通用仓储接口
先明确契约，避免过度设计。一个实用的 IRepository<T> 通常只需覆盖最常用操作：
- GetById(id)：按主键查单条（约定主键名为 Id 或 T 的 KeyAttribute）
- GetAll()：查全部（慎用，建议带分页）
- Find(sql, param)：自定义查询入口，保持 Dapper 灵活性
- Insert(entity)：插入并返回新 ID（如支持）
- Update(entity)：按主键更新非空/指定字段（可用 Expression 或显式字段列表）
- Delete(id)：按主键删除
实现基础仓储类
继承 IDbConnection 或注入 IDbConnectionFactory，避免在类里 new Connection —— 连接生命周期应由调用方或 DI 控制。关键点：
- 用 typeof(T).GetProperties() + 自定义特性（如 [Column], [Key]）识别映射关系，不依赖约定俗成的 “Id” 名
- Insert 和 Update 操作生成动态 SQL 时，跳过 readonly、static 或标记为 [NotMapped] 的属性
- Update 推荐使用 WHERE Id = @Id + 显式 SET 子句，不走全量更新，避免误覆写
- 所有方法接受可选 IDbTransaction 参数，方便上层聚合多个操作
处理泛型与 SQL 构建的边界
Dapper 本身不提供 IQueryable，所以不要试图在 IRepository 上加 Where、OrderBy 等 LINQ 方法——那会引入表达式树解析，得不偿失。正确做法是：
- 把查询逻辑下沉到具体仓储（如 UserRepository），它可继承 Repository<User> 并暴露 FindByEmail(string)、FindActiveWithOrders() 等语义化方法
- 通用接口只留 Find(string sql, object param)，让上层拼 SQL 或用 SqlBuilder（Dapper.Contrib 不推荐，但 DapperExtensions 已停更；可轻量封装自己的 SqlBuilder）
- 分页统一用 OFFSET-FETCH（SQL Server）或 LIMIT-OFFSET（PostgreSQL/MySQL），由具体方法如 GetPaged(sql, param, page, size) 承担
注入与使用示例（.NET 6+）
注册时用作用域生命周期，连接字符串通过工厂创建：
services.AddScoped(typeof(IRepository<>), typeof(Repository<>)); services.AddSingleton<IDbConnectionFactory, SqlConnectionFactory>();
业务中使用：
public class UserService {
private readonly IRepository<User> _userRepo;
public UserService(IRepository<User> userRepo) => _userRepo = userRepo;
public async Task<User> GetByOpenIdAsync(string openId)
=> await _userRepo.FindFirstOrDefaultAsync("WHERE OpenId = @OpenId", new { OpenId = openId });
}
注意：通用仓储不替代领域服务，它只是数据搬运工。复杂业务逻辑、跨表一致性、事务边界仍应在 Application Service 层组织。
基本上就这些。不复杂但容易忽略的是连接管理、主键识别健壮性和 SQL 注入防护——所有参数必须走 Dapper 的 parameterized query，绝不用字符串拼接。
