News

Have you heard me speak?

Upcoming Events

Visual Studio Live! 2011 - 10/17/2011

Find me here: No Fee Speakers, Asia Speakers, South Pacific Speakers, Europe Speakers, Africa Speakers, Latin America Speakers, South America Speakers, United States Speakers, Canada Speakers, Men Speakers, English Speakers

Navigation

Entity Framework 4.1– beware of the DbSet.Find method

One of the new features of Entity Framework 4.1 is the DbContext API which is basically a simplification of the ObjectContext API, and is intended to make your life a bit easier.

In this new API you can find the DbSet.Find method which according to MSDN does the following:

“Uses the primary key value to attempt to find an entity tracked by the context. If the entity is not in the context then a query will be executed and evaluated against the data in the data source, and null is returned if the entity is not found in the context or in the data source…”.

The section I underlined (“evaluated against the data in the data source”) is the one that you should beware of - the inner implementation of the Find() method creates a query that runs in the database and searches the entity set for the entity you want to find according to the ID which is passed to the method.

Now what’s wrong with the sentence I just wrote? it searches for the entity according to the ENTITY SET, not the entity type! This is a snippet from the implementation (using ILSpy):

If your model uses simple entity types, with no inheritance between them, you won’t have a problem with the Find() method, but… if your model contains an inheritance tree, and you try to use the method to find a derived type, then the method will create a query that searches the entire class hierarchy from the base type downwards – in all the child tables, instead of looking into the specific entity type’s table. This type of query will at the minimum take more time to execute because of all the joins between the tables, and in the worst case scenario – if you have many entity types mapped to different tables, it will crash because it will try to created a nested query with too many levels (check the “Query Complexity” section in the Performance Considerations for EF in MSDN).

What can you do? if you have a base type for all your entities, first ask yourself why you need the base type, since it usually creates problems with Entity Framework – there are several ways to overcome this, either by using interfaces, or by using base types not mapped to the EF model. If you do need the inheritance and do want to use the Find method’s technique of first looking in the loaded entities before searching the database, just write an extension method for the DbSet that first searches the loaded entities by looking in the DbSet.Local collection and if the entity isn’t found, run a SingleOrDefault query in the database.

Posted: Aug 01 2011, 02:36 PM by Ido Flatow | with 5 comment(s)

תגים:Bug, Entity Framework, DEV, dbset.find, nested query, dbset, entity framework 4.1

Comments

DotNetKicks.com said:

You've been kicked (a good thing) - Trackback from DotNetKicks.com

# August 1, 2011 2:49 PM

Ido Flatow said:

This is a comment I got on DotNetKicks and my reply to it:

Usually, we do not create complex inheritance trees while using Entity framework. The maximum depth of inheritance is usually 2. So, the case of the application crashing because of finding an entity is very remote. This is one more reason why we should avoid inheritance while using Entity framework.

Reply:

The matter is not only the depth of the tree, but also the number of derived types - when using queries on entity sets, the query will include all entity types, so it doesn't matter how deep your tree is but how many "nodes" you have in the tree.

One thing I see in models people build is that they use a "base entity" for all of their entity type, so if you have 50 entities which is not that far fetched, you would get a query spanning 50 tables, and that can easily throw an sql exception.

Usually people use base classes for common properties such as ID, version, etc..., but today with EF 4/4.1 you can implement it quite easily with interfaces, or even with base types that do not participate in the model (this is thanks to the T4 templates and code first options).

I don't think that the saying "avoid inheritance in EF" is correct - there are many situations where it is needed, one situation for instance is the need for polymorphism in collections, and is not always easy to implement using interfaces. What I am saying is that if inheritance is used, you must understand its meaning. Also, from my experience in EF, using a base entity for all the entity types is bad EF design, it will simply a lot of problems when running queries and when loading the model metadata into the memory, and should be avoided. Fortunatelly, EF 4/4.1 has easy ways to solve this using T4 and code first, as I mentioned before.

# August 2, 2011 9:56 AM

Laster said:

I don't even know how I ended up here, but I thought this post was good. I don't know who you are

but certainly you are going to a famous blogger if you aren't already ;) Cheers!

# July 23, 2012 9:02 AM

Orth said:

Wow! In the end I got a blog from where I be capable of actually take helpful

information regarding my study and knowledge.

# August 6, 2012 8:39 PM

Rushing said:

It's hard to come by experienced people about this subject, however, you sound like you know what you're talking

about! Thanks

# March 31, 2013 9:42 AM

Ido Flatow's Blog

Veni Vidi Scripsi

Recent Posts

Tags