可以在EF6上发出查询之前始终检查DbSet.Local

Question

I was reading about caching and performance with Entity Framework 6 and I had this ideia of always checking the DbSet.Local collection before issuing any query to the database, if the purpose of the query is to load a single entity information. So this is the pattern I came up with:

pubilc TAccount LoadByUsername<TAccount>(string username)
{
    TAccount acc = null;

    // Check cache.
    acc = DbEntitySet.Local.FirstOrDefault(a => a.Username.Equals(username, StringComparison.CurrentCultureIgnoreCase));

    if (acc == null) {

        // Then try and load from db.
        return await DbEntitySet.FirstOrDefaultAsync(u => u.Username.Equals(username)).WithCurrentCulture();
    }

    return acc;
}

I believe the overhead of checking Local is neglectable, considering the benefit of avoiding a db roundtrip + db processing.

With that said, I proceeded to read the Identity Framework source code to check whether they did anything similar, and I found out that they always issue another query, even with a high chance of the data being already in memory, which means that this:

FindById(accId);
FindByUsername(username);
FindByUsername(username);
FindByUsername(username);

causes 4 roundtrips to the db, even if the username parameter is the username of the account loaded by FindById .

Here's my question: am I onto something here, or this pattern just isn't safe? I'm not sure whether I should use this, considering Identity doesn't use anything similar, and the authors have more knowledge than me, obviously. Is DbSet.Local safe this way?

--Update

I just found a piece of code that cracks open LINQ queries passed as parameter to check whether it includes a select by id so they can check the cache for the entity before going to the db (via call to DbSet.Find ). So, I guess I'm onto something, just can't understand why they didn't extend this idea to methods such as "FindByEmail".

Answer 1

Really interesting question, I'm having some issues with just this.

It looks safe for the example you posted. You are looking for a single entity with a known key value. I think you find it isn't so safe in different circumstances, though.

For example, I've inherited some code where the repository uses local (cached) results first, and then falls back on issuing the query to the database if there is no result:

    public List<T> LoadAll(Expression<Func<T, bool>> expression)
    {
        var localResult = _dbSet.Local.AsQueryable().Where(expression).ToList<T>();

        return localResult.Count > 0 ? localResult : _dbSet.Where(expression).ToList<T>();
    }

This is great, most of the time, but I have hit a problem when issuing two requests to LoadAll for overlapping results. eg load an image list with images 1 and 2 in, then load an image list with images 2 and 3 in. Both queries are fulfilled using the local cache, but the second one incorrectly only includes image 2. Image 3 isn't in the local cache yet.

I either need to rework the calling code to pre-load all images to the cache, or I need to remove the locally cached results from any method which returns a list.

I can't see an obvious way to work out when the cached query result isn't good enough and issue the non-cached query instead.

MS has posted an article where the local results are bound directly to a UI ( https://msdn.microsoft.com/en-us/library/jj592872(v=vs.113).aspx ). This fits well in the instance where you want to be able to make changes and commit them all in one go. Not so sure it extends brilliantly well beyond that.