Open Closed

Power Tools - Table splitting #7348


0
Quiver created

Hello.

We just started using Power Tools for the first time in our new project (DDD heavy) and already faced some issues. First of all, let me explain some of our premises:

  • Our domain must have multiple definitions for a same entity. Ex: when a person is handled by the sales department, he/she is considered a lead and we need just some basic contact info about that person. When the same person is handled by the billing department, he/she is considered a customer and we need a lot more info (payment, address, etc.)
  • Even if our domain separates people into multiple entities, the database table should be unique: dbo.People, containing all the fields
  • Every domain must have it's own project, referencing the MyApp.Core project. On each of those projects we'll keep the entities, domain services, etc.

Now for the issues:

When creating table splitted entities, the relationship between them is not automaticaly configured. The workaroud is to never check the "Generate migration" and "Update database" fields and set up the relationship manualy:

modelBuilder.Entity<Lead>().ToTable("Person");
modelBuilder.Entity<Customer>().ToTable("Person");

modelBuilder.Entity<Customer>()
    .HasOne<Lead>().WithOne().HasForeignKey<Customer>();

Then we can create the migration and update the database via command line. EF kind of demands that you set up a relationship, even if there's no logical connection between the entities (other than the table), because everything else is treated separately (even projects, services, etc.)

Another issue is when multiple entities have shared properties:

public class Lead: Entity {
  public string Name {get;set;}
}

public class Customer: Entity {
  public string Name {get;set;}
  // many other properties
}

Ther generated migrations creates the Products table, but with two "name" columns (name and classb_name). Again, this prevent us from using the "Generate migration" and "Update database" options and we need to handle the splitting manualy:

modelBuilder.Entity<Lead>().ToTable("Person");
modelBuilder.Entity<Customer>().ToTable("Person");

modelBuilder.Entity<Customer>()
    .HasOne<Lead>().WithOne().HasForeignKey<Customer>();

modelBuilder.Entity<Lead>()
    .Property(e => e.Name).HasColumnName("Name");
    
modelBuilder.Entity<Customer>()
    .Property(e => e.Name).HasColumnName("Name");

Finaly, when we the entities are organized in multiple projects (say we want Lead on MyCompany.Sales project and Customer on MyCompany.Billing project), specifing the "Namespace" field on Power Tools will not check where the namespace root is and always create the entities on the MyCompany.Core project.

It's not completely impossible for us to work with Power Tools this way, but it requires a lot of manual and repetitive work to make things work properly. It would be nice if Power Tools had a better support for table splitting and multi-project entities.


3 Answer(s)
  • 0
    ismcagdas created

    Hi @Quiver

    Power Tools has a limited support actually. How many entities do you have like this one in your project ? When we were designing Power Tools, we didn't think about rate use cases.

  • 0
    Quiver created

    Hi @ismcagdas

    We are developing incrementally, so for now we're talking about 50 entities spread across 3 different domains, but eventualy (2+ years) the application should grow to about 540+ entities spread across 10 different domains. This is to support a structure that takes care of about 2.700 tenants, each with a 20-400GB database each.

    As I said, we can still use Power Tools and get the job done, but there's some time loss on moving classes from the Core project to the correct domain project and adjusting the relationships and column names on the DbContext before running migrations. You can consider this more like a suggestion for future releases.

  • 0
    ismcagdas created

    Thanks @Quiver

    If you can create an issue on https://github.com/aspnetzero/aspnet-zero-core, we can put it into Backlog and evaluate for the next versions of Power Tools.