Differences between .CreateObjectSet, .Set, and .CreateQuery?

Question

I am writing a generic repository for entity framework and am confused as to what the difference between these calls are:

ObjectContext.CreateObjectSet<T>
ObjectContext.CreateQuery<T>
DbContext.Set<T>

I want a generic repository that both supports context generated from .edmx files as well as code first DbContext, so I've got this:

 public abstract class EntityRepository<TClass>
   where TClass : class, new()
{
    //private readonly TContext _context;
    private readonly ObjectSet<TClass> _objectSet;

    protected EntityRepository(IObjectContextAdapter context)
    {
        _objectSet = context.ObjectContext.CreateObjectSet<TClass>();

    }

    protected EntityRepository(ObjectContext context)
    {
        _objectSet = context.CreateObjectSet<TClass>();
    }

    public ObjectSet<TClass> Query()
    {
        return _objectSet;
    }
}

In the examples I have seen online I've seen all 3 used, what is the actual differences between them? Is one better performance wise? I know you can write LINQ queries against the contexts using all 3 methods.

cincura.net · Accepted Answer · 2012-01-21T06:13:23.863

16

The CreateObjectSet<T> returns you ObjectSet<T> that's basically collection of T objects, with ability to add, remove, ... object from this collections resulting later to inserts, deletes, ... You can also use it for querying. It's like a top level root for given entity.

The CreateQuery<T> gives you ObjectQuery<T>, which can be viewed like IEnumerable<T> (it's also IQueryable<T>). This object is like subset of ObjectSet<T> (some conditions etc.), but you can't add items to it and so on.

And finally the Set<T> returns DbSet<T> that's simplified version of first method/object for Code First. It's easier to, for instance, to use these objects (or better to say interfaces; IDbSet<T>) for i.e. unit testing etc. Similar to what ObjectContext and DbContext is.

edited Jan 21 '12 at 06:13

answered Jan 20 '12 at 20:47

cincura.net

4,130
16
40

So there is really no performance differences when running queries against the database for each of these? In my case since my Repository isn't storing the actual context, would you say I went the right path of choosing ObjectSet so I can do all CRUD operations with it? – SventoryMang Jan 20 '12 at 20:58
2

Fundamentally, and ObjectSet: ObjectQuery. Whether you build your query using one or the other doesn't affect query execution. There is minimal overhead in the call to CreateObjectSet compared to CreateQuery (we do some metadata lookups) but I would be suprised if this overhead had any observable impact in the real world. The implemetnation of Set on the DbContext API is really a thin layer over the other methods. It shouldn't have a significant impact either, and DbContext as a whole is much simpler and easier to use API. – divega Jan 20 '12 at 23:03

score 4 · Answer 2 · answered Jan 20 '12 at 22:56

In addition to what Jiri already explained, there is an overload of CreateObjectSet that takes no arguments. This overload will automatically assume that it has to return the ObjectSet for the only EntitySet associated with TEntity. It will throw if the model has MEST (multiple-entity-sets-per-type). All overloads of CreateQuery need an Entity SQL string to bootstrap the query (note that the name of an EntitySet is a valid Entity SQL query).

Differences between .CreateObjectSet, .Set, and .CreateQuery?

2 Answers2