直接 new Repository() 会破坏依赖倒置，因将数据访问细节泄露至业务层；应仅在 Composition Root 注册实现并依赖注入 IRepository<T>。
为什么直接 new Repository() 会破坏依赖倒置
仓储模式不是写个 IRepository<T> 接口再实现一个类就完事了。核心陷阱在于：如果业务层直接 new SqlRepository<User>()，等于把数据访问细节（比如 SQL Server 依赖、连接字符串硬编码）泄露到了上层，后续换 MongoDB 或单元测试时根本没法替换。
真正可行的做法是只在 Composition Root（如 Program.cs 或 DI 容器配置处）注册具体实现：
services.AddScoped(typeof(IRepository<User>), typeof(SqlRepository<User>));
业务类只依赖 IRepository<User>，运行时由容器注入具体类型——这才是“面向接口编程”的落地点。
IRepository 该定义哪些方法才不算过度设计
很多教程一上来就塞满 GetAllAsync、FindAsync、CountAsync、AnyAsync……结果发现 80% 的接口永远只被调用一次，还导致泛型约束越来越复杂。
推荐最小可用集（按真实使用频率排序）：
-
Task<T> GetByIdAsync(int id)—— 主键查询几乎必用，ID 类型可按需泛化为TKey -
Task<IReadOnlyList<T>> ListAsync(Expression<Func<T, bool>> predicate)—— 支持简单条件查，不暴露 IQueryable 防止业务层拼接 SQL -
Task AddAsync(T entity)—— 新增，返回 void 或 Task 即可，别搞同步阻塞版 -
Task UpdateAsync(T entity)—— 更新，由实现类负责跟踪状态（如 EF Core 中的Attach+Entry().State = Modified） -
Task DeleteAsync(int id)—— 软删或硬删逻辑封装在实现里，接口不暴露底层细节
别加 SaveChangesAsync() —— 事务边界应由上层（如 Application Service）控制，仓储只管单实体操作。
EF Core 下 SqlRepository 怎么避免 DbContext 生命周期污染
常见错误是把 DbContext 当作仓储字段长期持有：private readonly AppDbContext _context;。这会导致上下文跨请求复用，引发 InvalidOperationException: A second operation started on this context before a previous operation completed。
正确做法是每次方法调用时获取新作用域内的上下文实例：
public class SqlRepository<T> : IRepository<T> where T : class
{
private readonly Func<AppDbContext> _contextFactory;
public SqlRepository(Func<AppDbContext> contextFactory) => _contextFactory = contextFactory;
public async Task<T> GetByIdAsync(int id)
{
using var ctx = _contextFactory();
return await ctx.Set<T>().FindAsync(id);
}
}
注册时配合工厂模式：
services.AddScoped<Func<AppDbContext>>(sp => () => sp.GetRequiredService<AppDbContext>());
这样每个仓储方法都拿到独立的上下文实例，线程安全且符合 EF Core 推荐生命周期（Scoped）。
Where 表达式传入仓储后无法翻译成 SQL 怎么办
当你写 repo.ListAsync(x => x.Name.ToUpper() == "ADMIN")，EF Core 可能报错 System.InvalidOperationException: The LINQ expression could not be translated —— 因为 ToUpper() 在数据库里没对应函数，或方言不支持。
关键原则：仓储接收的 Expression<Func<T, bool>> 必须能被 EF Core 完整翻译。实操建议：
- 优先用
string.Equals(a, b, StringComparison.OrdinalIgnoreCase)替代a.ToUpper() == b.ToUpper() - 避免在表达式里调用自定义方法、本地函数或非 EF 支持的扩展方法
- 复杂查询不要硬塞进仓储，改用专门的
IQueryHandler<TRequest, TResponse>模式（CQRS 分离） - 调试时开启 EF 日志：
options.LogTo(Console.WriteLine)，看生成的 SQL 是否符合预期
仓储不是万能查询引擎，它只负责“按约定条件查一批”，真要动态拼 where、join、group，交给专用查询类更可控。
