Entity Framework 6 DBContext with only a subset of all tables

Question

We have a huge database with 770 tables and we want to conduct performance testing using EF 6.1x.

We want to query only 5 of these 770 tables. Is it possible to create a “lightweight” DBC text with 5-6 entities / DBSets instead of using the full 770-tables context?

When we use the full context, a simple request with 4 connections takes 45 seconds. It is 44 seconds too long. We use the first code (reverse design).

Problem: When we create such an “easy” version of the full context (i.e., Only 5 tables), EF complains that all other objects that are somehow related to these 5 tables have missing keys. We display only keys, properties, relationships for these 5 tables, but not the rest.

Since a query written in LINQ only requests 5 tables, EF should just ignore the remaining 765 tables, but it will not. Why not? LazyLoading = true / false does not seem to have anything to do with this.

Note. Obviously, you can create a database view that does what we do in the LINQ query code. The question is whether this can be done using the "light" DbContext, as described above.

There is a light version of the context:

public class ItemLookupContext : DbContext { static ItemLookupContext() { Database.SetInitializer<ItemLookupContext>( null ); } public ItemLookupContext() : base( "Name=ItemLookupContext" ) { //Configuration.LazyLoadingEnabled = true; } public DbSet<Identity> Identities { get; set; } public DbSet<Item> Items { get; set; } public DbSet<Price> Prices { get; set; } public DbSet<Department> Departments { get; set; } public DbSet<Brand> Brands { get; set; } protected override void OnModelCreating( DbModelBuilder modelBuilder ) { modelBuilder.Configurations.Add( new IdentityMap() ); modelBuilder.Configurations.Add( new ItemMap() ); modelBuilder.Configurations.Add( new PriceMap() ); modelBuilder.Configurations.Add( new DepartmentMap() ); modelBuilder.Configurations.Add( new BrandMap() ); //ignore certain entitities to speed up loading? //does not work modelBuilder.Ignore<...>(); modelBuilder.Ignore<...>(); modelBuilder.Ignore<...>(); modelBuilder.Ignore<...>(); modelBuilder.Ignore<...>(); } } 

Answer 1

what are you trying to do something like "limited context", which is one of the DDD patterns

So you can check out this article by Julie Lerman, Shrink EF Models with Limited DDD Context

Answer 2

If you have a one-to-one relationship between class A and class B :

 public class A { public B b {get; set;} } public class B { public ICollection<A> As {get; set;} } 

and determine the following DbContext , EF automatically includes the DbSet<B> in the DbContext :

 public class MyContext : DbContext { ... public DbSet<A> As { get; set; } } 

So, if you want your DbContext light DbContext not DbContext on the associated DbSet s, just use the Ignore method:

 public class MyContext : DbContext { ... public DbSet<A> As { get; set; } protected override void OnModelCreating( DbModelBuilder modelBuilder ) { modelBuilder.Ignore<B>(); } } 

Answer 3

Just create your DBC text for your tables. To prevent Entity Framework from moaning about tables that are not mapped, you disable db initialization in your application. Put this in your global.asax / Startup.cs file

 Database.SetInitializer<YourDbContext>(null); 

It tells EF to stop comparing your actual DB structure with your DbContext. It also means that if someone modifies your mapped EF tables, you have no chance of getting notified.

Answer 4

It looks like you used a tool like Entity Framework Power Tools to create entity classes and mappings. This would create a class for each table in the database, a huge context, comparisons for all of these classes and all possible associations. It's too much.

First remove all classes and mappings that you do not need. Then remove all associations with deleted classes from the few remaining classes, not the primitive foreign key fields. Also, remove all DbSets from the context, with the exception of the few that you need.

This slimmed-down model will be consistent in itself. It will not have associations with all objects in the database, but it will be possible to filter foreign key values ​​that refer to objects out of context.

If you generated / created the code in any other way, this is still the key: use the navigation properties for other classes in the class model. For other references, primitive foreign key properties are used.