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

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.