Foreign Keys not named correctly on code generation

Similar to my last one, sort of.

Same three tables:

in the context, it generates:

modelBuilder.Entity<EFCoreDesignTools.JoinSiteInvestigator>()
    .HasOne(x => x.Site)
    .WithOne()
    .HasForeignKey("Site_Id")
    .IsRequired().OnDelete(DeleteBehavior.Cascade);
modelBuilder.Entity<EFCoreDesignTools.JoinSiteInvestigator>()
    .HasOne(x => x.Investigator)
    .WithOne()
    .HasForeignKey("Investigator_Id")
    .IsRequired().OnDelete(DeleteBehavior.Cascade);

.HasForeignKey("Site_Id") and .HasForeignKey("Investigator_Id") should be generated as “SiteId” and “InvestigatorId” respectively.

I’m not sure if this is an issue with how the relationships are set up, or an issue with the generator?

[msawczyn]

Yes, EF6 will create the needed database structures without messing up your object model. EFCore will eventually get there, but it’s slow going.

The ideal case is that you model your classes like you would model any classes. Persistence is something EF takes care of, and you shouldn’t really have to care how it does it. That’s why I rail against putting foreign key properties in a class – you wouldn’t put them there if it weren’t persistent, would you? – and in using the LINQ Join statement … too databasey.

EFDesigner’s philosophy is that you’re modeling classes, not tables. Sure, there are a few properties that point to the fact that persistence is done via database tables, but that’s because we don’t live in a perfect world. Except for the connection string and maybe one or two other properties, the defaults serve well enough that you shouldn’t really have to mess with them.

I use Tangible’s editor. It says that it doesn’t like string interpolation (the $“string” thing), but that doesn’t matter … at runtime it just works, since the .NET version at runtime is more up-to-date than then one they use at edit time. (They should update that.)

[johnhenley]

Can you reopen this issue?

I have started evaluating EFDesigner, and run into a similar issue with the “_Id” being generated as the default suffix for a foreign key. In my situation, the relationship is a simple one, not a many-to-many.

According to Microsoft docs, “ID” is the “standard” for the foreign key suffix as specified here (see section “Renaming a Foreign Key That Is Not Defined in the Model”): https://docs.microsoft.com/en-us/ef/ef6/modeling/code-first/fluent/types-and-properties

It would be nice to have the suffix definable in the .efmodel properties, so that “_Id” or “ID” or “Id” can be specified as the default, and even could be overridden in each association perhaps.

In the meantime, I guess the solution is to copy and modify the .ttinclude directly in a given project.