Difference between DbSet property and Set() function in EF Core?

Question

Given this kind of context:

public class FooContext : DbContext 
{
    public FooContext(DbContextOptions<FooContext> opts) : base(opts)
    { }

    public DbSet<Bar> Bars { get; set; }
}

I can get to a Bar in two ways:

fooContext.Bars.Add(new Bar()); // Approach 1

or

fooContext.Set<Bar>().Add(new Bar()); // Approach 2

What is the difference between the two approaches?

I've tried to answer my own question by:

Inspecting the intellisense for both (only tells me that Set<T>() also creates a DbSet<T>)
Googling for "EF Core Set vs property" but that doesn't seem to be the 'right' query
Google for DbSet<T> specifically on the docs urls but no relevant results here either it seems
Reading the intro of the DbSet<T> docs which just suggests that you can get a set through either of the two methods (not if there is or isn't a difference)
Read the Set<T>() docs which has no relevant info

But I could not find any good explanation about which of the two is used for which purpose. What is the difference? Or perhaps more importantly: where and how should I be able to find this in the docs?

They appear to do the same thing: https://github.com/aspnet/EntityFrameworkCore/blob/master/src/EFCore/DbContext.cs Line 245. The difference I think is that `Set` will use IDbSetSource to lookup the type at runtime and work out what table it requires, whereas `Bar` property does this at compile time. — Ben, Nov 25 '18 at 17:20
@Ben Ahh yes of course. Several years down the road and I still need the occassional reminder that Microsoft open sources just about anything in this space. Thanks! — Jeroen, Nov 25 '18 at 17:50
Has anyone done performance tests on using DbSet property vs Set() method on a context with a large number of mapped entities? I'm working in an app with about 200 entities. The DbContext can either have 200 properties for all of the entities or the Set method can be used for the individual entities needed in a particular location. I'm curious if the work to spinup a context with so many DbSet properties is likely to be slower than just using the Set method as needed. The app will use DI to inject a DbContext in a MVC app so a new object will be created for each request. — StuffOfInterest, Oct 30 '19 at 20:26

score 27 · Accepted Answer · answered Nov 25 '18 at 17:29

They do exactly the same thing. The real question is when will you use one over the other.

You use DbSet when you know the type of entity you want to play with. You simple write the DbContext name then the entity type name and you can create, read, update or delete entries for this entity with the entity methods available. You know what you want and you know where to do it.

You use Set when you don't know the entity type you want to play with. Lets say, you wanted to build a class that does your repository functions for creating, reading, updating and deleting entries for an entity. You want this class to be reusable so that you can just pass a DbContext on it and it will use the same create, read, update and delete methods. You don't know for sure what DbContext it will be used on or what DbSet the DbContext will have. Here's when you use generics so that your class can be used by any DbContext for any DbSet.

Here's an example of a class you can use for creating any entity on any DbSet in any DbContext

public class Repository<TDbContext> where TDbContext : DbContext
{
    private TDbContext _context { get; }

    public Repository(TDbContext context)
    {
       _context = context;
    }

    public TEntity Create<TEntity>(TEntity entity) where TEntity : class
    {
        if(entity != null)
        {
            var dataSet = _context.Set<TEntity>();

            if(entity is IEnumerable)
            {
                dataSet.AddRange(entity);
            }
            else
            {
                dataSet.Add(entity);
            }

            _context.SaveChanges();


        }

        return entity;
    }
}

And this is how to use it.

var dbContext01 = new DbContext01();
var dbContext02 = new DbContext02();

var repository01 = new Repository<DbContext01>(dbContext01);
var repository02 = new Repository<DbContext02>(dbContext02);

repository01.Create(new EntityOnDbContext01 {
    Property01A = "String",
    Property01B = "String"
});

repository02.Create(new EntityOnDbContext02 {
    Property02A = 12345,
    Property02B = 12345
});

Here's a link if you want to know more about generics. Its super awesome.

https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/

So going back to the question, if I make a call like ```fooContext.Set().Add(new Bar());```, how does it correspond to the ```public DbSet Bars { get; set; }``` in the ```FooContext``` class definition? Does the ```Set()``` function perform a search in the ```FooContext``` class for existing properties of type ```DbSet``` and returns it (if it can find it)? What if it doesn't exist? What if there are multiple properties of that same ```DbSet``` type? Or perhaps it makes its own new property? — aldo, Sep 28 '22 at 14:50

score 11 · Answer 2 · answered Nov 25 '18 at 18:21

Unfortunately currently you won't find explanation in the official documentation, mainly because all these are functionally equivalent.

First, the generic methods of DbConext like Add<TEntity>, Remove<TEntity>, Attach<TEntity> etc. a fully equivalent of the corresponding DbSet<TEntity> methods (actually currently they are the implementation of the later, i.e. DbSet methods simply call the corresponding DbContext generic method). Which one you use is just a matter of taste.

Second, DbSet<TEntity> property and Set<TEntity> method are functionally equivalent, but do have some non functional differences.

The DbSet properties are populated once at the context creation, while Set method always performs a lookup, so DbSet property access should be faster than Set method (although not significant).

The important difference is actually the EF Core Including & Excluding Types convention:

By convention, types that are exposed in DbSet properties on your context are included in your model. In addition, types that are mentioned in the OnModelCreating method are also included.

So while you can keep your DbContext without exposed DbSet properties and work just with Set method, if you do so you have to tell explicitly EF Core which are your entity types by adding in OnModelCreating a call to modelBuilder.Entity<TEntity>(); for each entity type (this is what the documentation does mean by types that are mentioned in the OnModelCreating method).

I cannot agree that DbSet methods are the same implementation as DbContext.Add and so on. I did not have looked at the code, but in EfCore 6 I did get some differences. When I tried to add entity using DbContext.Add and this entity was added as DbSet in my DbContext there were some problems. For some reason, when entity is in DbContext as DbSet, I needed to use: DbContext.MyEntityDbSet.Add instead of DbContext.Add — Adam Jachocki, May 09 '22 at 10:00

score 1 · Answer 3 · answered Nov 25 '18 at 17:36

They are the same and actually returns the same DbSet instance.

var options = //...;

using (var ctx = new FooContext(options))
{
    // true
    bool isSame = ReferenceEquals(ctx.Bars, ctx.Set<Bar>());
}

One use case for not including a DbSet property in your DbContext is when you want to hide an entity type from a consumer. (e.g. an entity that acts as join table for many-to-many relationship). You can then mark the entity as internal class so consumers also can't also access it using Set<>.

Also, if you don't expose a DbSet property, you need to explicitly configure the entity or you'll get the following exception:

//throws System.InvalidOperationException: 'The entity type 'Foo' was not found. Ensure that the entity type has been added to the model.'
ctx.Set<Foo>().Add(new Foo());

Difference between DbSet property and Set() function in EF Core?

3 Answers3

Linked