EF Core 不内置仓储模式，推荐按聚合根建具体仓储（如IProductRepository），聚焦业务语义、内聚查询逻辑；通用仓储易导致扩展难、性能差，DbSet本身已具仓储与查询功能；简单场景可直接用DbSet。
EF Core 本身不内置仓储模式，但你可以基于 DbContext 和 DbSet<T> 轻量封装出符合业务需要的仓储，既保持灵活性，又避免过度抽象带来的复杂性。
为什么不用“通用仓储”？
很多教程一上来就写一个 IRepository<T> 接口加泛型实现，结果发现：查询条件难扩展、Include 关系难控制、性能问题频发、最终还是绕回 DbContext。EF Core 的 DbSet<T> 本身就是一种“仓储+查询对象”的混合体，强行套用传统 .NET Framework 时代的通用仓储，反而增加冗余。
推荐做法是：按聚合根或核心业务实体建具体仓储，比如 IProductRepository、IOrderRepository，每个只暴露该领域真正需要的操作。
如何写一个实用的 ProductRepository
以商品管理为例，定义接口和实现：
-
接口聚焦业务语义：不叫
GetById，而叫FindActiveById或FindWithCategories，体现业务规则 - 构造函数接收 DbContext：避免在仓储里 new DbContext，利于依赖注入和生命周期管理
-
查询逻辑内聚在仓储中：把
Include(x => x.Category)、.AsNoTracking()、软删除过滤等收拢，上层服务不用关心
示例代码片段：
public interface IProductRepository<br>{<br> Task<Product> FindWithCategoriesAsync(int id);<br> Task<IList<Product>> ListByCategoryAsync(string categorySlug, int page = 1, int size = 20);<br> Task AddAsync(Product product);<br> void Update(Product product);<br>}
仓储 + Specification 模式（可选进阶）
如果多个仓储都需要动态查询（如“已上架且库存 > 0 的商品”），可引入 ISpecification<T> 封装表达式逻辑：
- Specification 定义
Expression<Func<T, bool>> Criteria和IEnumerable<Expression<Func<T, object>>> Includes - 仓储方法接收
ISpecification<Product>，用ApplyCriteria和ApplyIncludes组装 IQueryable - 好处：复用查询逻辑、解耦条件与执行、测试友好
什么时候直接用 DbSet 就够了？
不是所有场景都需要仓储：
- 内部工具、原型项目、CRUD 极简管理后台 → 直接在 Service 中注入
DbContext调用DbSet更快更透明 - 领域模型简单、无复杂查询或跨上下文协作 → 仓储可能纯属过度设计
- 团队对 EF Core 熟练、能统一约定查询规范 → 可用扩展方法替代部分仓储职责（如
context.Products.Active().WithCategory()）
基本上就这些。仓储不是必须品，而是为解决特定问题（如隔离 EF 细节、统一查询策略、适配测试替身）服务的手段。用 EF Core 做仓储，关键在“克制”——按需封装，不求全，不套模板。
