Entity Framework 6 DBContext with only a subset of all tables

Question

We have a huge database with 770 tables and want to do some performance testing with EF 6.1x.

We want to query only 5 of those 770 tables. Is it possible to create a "light" DBContext with only 5-6 entities/DBSets instead of using the full 770-tables-context?

When we use the full context, a simple query with 4 joins takes 45 seconds. Thats' 44 seconds too long. We are using code-first (reverse engineered).

The problem: When we create such a "light" version of the full context (i.e. 5 tables only), EF complains that all the other entities that are somehow related to these 5 tables have missing keys. We only map the keys, properties, relationships for those 5 tables, but not the rest.

Since the query written in LINQ only queries 5 tables, EF should simply ignore the other 765 tables, but it won't. Why not? LazyLoading=true/false doesn't seem to have any bearing on this.

Note: Obviously one could create a view in the DB that does what we do in code with a LINQ query. The question is can it be done with a "light" DbContext as above.

There's the "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 you trying to something like "Bounded Context" which is one of DDD patterns

So, you can check this article by Julie Lerman, Shrink EF Models with DDD Bounded Contexts

Answer 2

Simply just create your DBContext for your tables. To prevent Entity Framework moaning about the not mapped tables, you have switch off the db initialization in your application. Put this in your global.asax/Startup.cs

Database.SetInitializer<YourDbContext>(null);

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

Answer 3

When you have a many-to-one relation between class A and class B:

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

and define following DbContext, EF automatically includes DbSet<B> to the DbContext:

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

So, if you want your light DbContext does not includes the related DbSets, simply use Ignore method:

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

   protected override void OnModelCreating( DbModelBuilder modelBuilder )
   {
      modelBuilder.Ignore<B>();
   }
}

Answer 4

It looks like you used a tool like Entity Framework Power Tools to generate the entity classes and mappings. This would have generated a class for each table in the database, a huge context, mappings for all these classes and all possible associations. This is way too much.

First remove all classes and mappings that you don't need. Then remove all associations to removed classes in the few classes you have left, not the primitive foreign key fields. Also remove all DbSets from the context except the few you need.

This slimmed-down class model will be consistent in itself. It won't have associations to all entities in the database, but it will be possible to filter by foreign key values that refer to entities outside the context.

If you generated/created the code in any other way this is still the crux: only use navigation properties to other classes in the class model. For other references use primitive foreign key properties.