Dapper如何封装通用仓储 Dapper Repository模式实现方法

来源：这里教程网时间：2026-02-21 17:33:54 作者：

用 Dapper 实现通用仓储（Generic Repository）不是要完全照搬 Entity Framework 那套抽象，而是借其思想——统一数据访问入口、减少重复 SQL、提升可测试性与可维护性。核心在于：用泛型约束实体类型，用 Dapper 的轻量扩展能力封装增删改查共性逻辑，同时保留手写 SQL 的灵活性和性能优势。

定义通用仓储接口

先明确契约，避免过度设计。一个实用的 IRepository 通常只需覆盖最常用操作：

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 并暴露 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<&gt), typeof(Repository<&gt));
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，绝不用字符串拼接。