Question

All,

I have a requirement to hide my EF implementation behind a Repository. My simple question: Is there a way to execute a ‘find’ across both a DbSet AND the DbSet.Local without having to deal with them both.

For example – I have standard repository implementation with Add/Update/Remove/FindById. I break the generic pattern by adding a FindByName method (for demo purposes only :). This gives me the following code:

Client App:

ProductCategoryRepository categoryRepository = new ProductCategoryRepository();
categoryRepository.Add(new ProductCategory { Name = "N" });
var category1 = categoryRepository.FindByName("N"); 

Implementation

public ProductCategory FindByName(string s)
{
    // Assume name is unique for demo
    return _legoContext.Categories.Where(c => c.Name == s).SingleOrDefault();
}

In this example, category1 is null.

However, if I implement the FindByName method as:

public ProductCategory FindByName(string s)
{
    var t = _legoContext.Categories.Local.Where(c => c.Name == s).SingleOrDefault();
    if (t == null)
    {
        t = _legoContext.Categories.Where(c => c.Name == s).SingleOrDefault();
    }
    return t;
}

In this case, I get what I expect when querying against both a new entry and one that is only in the database. But this presents a few issues that I am confused over:

1) I would assume (as a user of the repository) that cat2 below is not found. But it is found, and the great part is that cat2.Name is “Goober”.

ProductCategoryRepository categoryRepository = new ProductCategoryRepository();
var cat = categoryRepository.FindByName("Technic");
cat.Name = "Goober";
var cat2 = categoryRepository.FindByName("Technic");

2) I would like to return a generic IQueryable from my repository.

It just seems like a lot of work to wrap the calls to the DbSet in a repository. Typically, this means that I’ve screwed something up. I’d appreciate any insight.

Answer 1

With older versions of EF you had very complicated situations that could arise quite fast due to the required references. In this version I would recomend not exposing IQueryable but ICollections or ILists. This will contain EF in your repository and create a good seperation.

Edit: furthermore, by sending back ICollection IEnumerable or IList you are restraining and controlling the queries being sent to the database. This will also allow you to fine tune and maintain the system with greater ease. By exposing IQueriable, you are exposing yourself to side affects which occur when people add more to the query, .Take() or .Where … .SelectMany, EF will see these additions and will generate sql to reflect these uncontrolled queries. Not confining the queries can result in queries getting executed from the UI and is more complicated tests and maintenance issues in the long run.

since the point of the repository pattern is to be able to swap them out at will. the details of DbSets should be completly hidden.

I think that you’re on a good path. The only thing I probaly ask my self is :

Is the context long lived? if not then do not worry about querying Local. An object that has been Inserted / Deleted should only be accessible once it has been comitted.

if this is a long lived context and you need access to deleted and inserted objects then querying the Local is a good idea, but as you’ve pointed out, you may run into difficulties at some point.