绕开DBSet调用DbContext的Find/Add等方法是否有弊端？能否省略DBSet？

这确实是个挺实用的问题——不少EF Core开发者可能都没留意到DbContext本身就提供了直接操作实体的方法，而非必须通过Set<TEntity>。咱们来仔细聊聊这个话题：

首先，明确本质：DbContext的方法只是语法糖 #

DbContext的Find(Type, object[])、Add(object)、Update(object)这些方法，内部逻辑其实就是先获取对应实体类型的DbSet<TEntity>，再调用Set上的同名方法。举个例子：

dbContext.Add(entity);
// 等价于
dbContext.Set<TEntity>().Add(entity);

EF Core会自动根据传入实体的类型推断出对应的DbSet，所以不存在真正意义上的“绕开”，只是少写了Set<TEntity>这层调用而已。

关于DbSet的性能消耗：几乎可以忽略 #

你提到的“创建或获取DBSet会消耗时间”其实无需担心——Set<TEntity>是个极轻量的操作。EF Core会在DbContext实例内部缓存所有DbSet，第一次调用Set<T>时创建实例，后续调用直接返回缓存的对象，性能开销微乎其微，完全不值得为这点牺牲代码的其他特性。

直接调用DbContext方法的潜在弊端 #

虽然语法上可行，但在很多场景下，直接用DbContext的方法会带来一些问题：

• 类型安全缺失：比如dbContext.Find(typeof(Product), id)，如果不小心把类型写成typeof(Order)，编译器不会报错，只有运行时才会抛出异常；而dbContext.Set<Product>().Find(id)是强类型的，编译期就能发现类型错误，这在大型项目里能提前规避大量bug。
• 自定义逻辑失效：如果你在自定义DbContext中重写了某个DbSet的方法（比如为DbSet<Product>的Add方法加了审计日志逻辑），直接调用dbContext.Add(product)不会触发你的自定义代码，因为它会调用默认的DbSet实现，而非你重写后的版本。但如果用dbContext.Products.Add(product)（显式定义的DbSet属性），就能正常执行你的自定义逻辑。
• 可读性与协作成本：绝大多数EF Core的官方文档、示例代码都是使用Set<T>或显式DbSet属性来操作实体，团队中的其他开发者更习惯这种写法。直接用DbContext的方法会让代码显得不够直观，增加团队成员的理解成本。

什么时候省略DbSet是合理的？ #

当然，也有一些场景下直接用DbContext的方法是合适的：

• 通用泛型工具类：比如你写一个泛型CRUD扩展方法，public static async Task<T> GetByIdAsync<T>(this DbContext context, object id) where T : class，这里用context.Find(typeof(T), id)或者context.Set<T>().Find(id)都可行，不过泛型场景下Set<T>的类型安全性更好。
• 小型项目/快速原型：在代码量少、团队规模小的场景下，类型出错的概率低，直接用db.Add(entity)可以少写冗余代码，提升开发效率。

总结 #

如果是小型项目、快速原型开发，直接调用DbContext的方法完全没问题；但在大型项目、需要类型安全、有自定义DbSet逻辑的场景下，更推荐使用Set<T>或显式定义的DbSet属性——这样代码更健壮、更易维护，也符合团队的通用开发习惯。

内容的提问来源于stack exchange，提问作者CleanCoder