Can you exclude reverse navigation properties in EF when eager loading?

Question

When I use the .Include syntax in EF6, reverse navigation properties are always loaded. Is there a way to turn that off? Here is a sample query.

private stat         


        

Answer 1

I think what you're seeing is a result of "relationship fix-up":

Relationship fix-up ensures that related objects are automatically linked when the second entity enters the ObjectContext.

http://blogs.msdn.com/b/alexj/archive/2009/10/13/tip-37-how-to-do-a-conditional-include.aspx

---

In your case, since you're including AccountLocation.Address.City, EF is loading the related Address entities and the related City entites that you requested, and as part of the "fix-up" it's adding the loaded Address entities that would be part of the City->Address one-to-many relationship to the City.Addresses navigation collection.

You can find another example at this link. As in your case, lazy loading and proxy creation were also disabled -- however, that link doesn't include a way to disable this behavior.

Answer 2

Can you exclude reverse navigation properties in EF when eager loading?

No.

As explained in another answer, EF has this process of relationship fixup that knits together all entities it has loaded into a context. You can't stop this process in any way. So if you don't take things in your own hands, you'll always end up having this bloated Json string. (I can't explain nor reproduce the eager loading differences you seem to find, but these should be the subject of a new question. I wouldn't count on them to always happen, hoping they will solve your current issue).

So that's the key here: take control. It depends on your situation what is the best strategy, but there are a few options.

1. Project the query into an anonymous type and serialize it into JSON. Just a minimal example:

   repository.Queryable()
             .Select(e => new 
             {
                  Account = e.Name,
                  AccountLocations = 
                      e.AccountLocations
                       .Select(l => new
                       {
                           Address = new { l.Address.Street, l.Address.Number },
                           City = l.Address.City.Name,
                           Country = l.Address.City.Country.Name,
                       })
             });
   

   Some people will frown upon returning anonymous types from a method, even if it's in JSON, but to me it's just a method that returns JSON in some desired format. It only brings the untyped JavaScript world one step closer.

2. Do the same with a structure of named types (DTO, or view model, types.

3. Create a dedicated context without bidirectional associations. This is an option that's often forgotten, but why should there always be one context by which you access your data? Only make sure that the classes used by (or generated by) the context have different names than the ones belonging to the main context.

By the way, by doing this you can also tailor the amount of data you fetch from the database to what you need to serialize.