实体框架 - 通用预加载（包括字符串）缺失级别

Question

My database contains a Vendor, Project,Address and Vendor_Project tables. Every Vendor has an address. I wrote a generic function that performs include to the levels received from input.

string[] includes = {"Vendor","Project"};
IEnumerable<Vendor_Project> vendorsOfProject = (IEnumerable<Vendor_Project>) await DataStore.Instance.vendorProjectsService.GetAll(includes);


public async Task<IEnumerable<T>> GetAll(string[] includes = null)
        {
            using (DeployToolDBContex contex = _contexFactory.CreateDbContext())
            {
                var query = contex.Set<T>().AsQueryable();
                foreach (var include in includes)
                    query = query.Include(include);
                return query.ToList();
            }
        }

In the above example I got the requested result but the address is null. How can i make that query worked for all levels and their sub levels?

Answer 1

For EF6 you would need to specify each child & grandchild as part of your Includes list, so {"child", "child.grandchild"} . For EF Core you will probably need to parse to perform an Include and ThenInclude and potential further levels of ThenInclude chaining down.

I would highly recommend reconsidering the approach where you feel you need Includes on something like a GetAll method. Instead, consider leveraging Projection to transform an entity graph down to a ViewModel with details from the entity and related entities. The problem with particularly Generic patterns like this is that you are committing to materializing a potentially huge portion of your database into memory. When fetching lists of entities you generally do not need every field from every related entity, but rather a few important fields/keys, and possibly some summary details or counts etc. from related entities.

Where you may typically still need to eager load related entities would be when fetching a single top-level entity with it's assortment of related entities such as to present a detailed view. For EF Core when you do have a legitimate case to eager load a lot of entities like nested child collections, you should leverage split queries so that EF will execute several queries against the database rather than attempting to join all related tables in one query. The difference is that for the default eager load JOIN implementation where you have 1 top level entity with 15 columns and 10 related child entities with 10 columns, each with up to 2 grand child entities with 8 columns you generate a Cartesian product to pull back all combined columns across all combined rows which EF then iterates through to build the entity graph. With split queries you still pull back all rows, but with separate queries so there is less data overall being sent.

The main reason you should avoid using eager loading for loading sets of data, especially things like "Get All" is that after transmitting and materializing all of those entities, by default the EF DbContext will be tracking each of those entities which means all further queries and such across that DbContext will involve comparing and inspecting the local tracked entities, slowing down future queries.