Dimitris,
Mapping a single navigation property to two different foreign keys is not something that is supported by core EF and is therefore also not supported by Code First
since Code First builds on top of core EF. It is possible to do something similar in core EF with TPC mapping where foreign key property/column is shared.
In this case there is one FK property/column but it refers to the PK in either Account table or the Contact table.
However, this currently doesn’t work with Code First in CTP5 because of some bugs in the TPC mapping code.
When the bugs are fixed something like this should work:
public abstract
class Customer
{
public virtual
Guid Id { get;
set; }
public virtual
string Name { get;
set; }
public virtual
ICollection<Order> Orders {
get; set; }
}
public class
Account : Customer
{
public virtual
string AccountNumber { get;
set; }
}
public class
Contact : Customer
{
public virtual
string FirstName { get;
set; }
public virtual
string LastName { get;
set; }
}
public class
Order
{
public Guid Id {
get; set; }
public string Name {
get; set; }
public Customer BillToCustomer {
get; set; }
public Guid BillToCustomerId {
get; set; }
}
public class
TpcRelationshipContext :
DbContext
{
protected override
void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Order>();
modelBuilder.Entity<Account>()
.Map(mc => { mc.MapInheritedProperties(); })
.ToTable("Accounts");
modelBuilder.Entity<Contact>()
.Map(mc => { mc.MapInheritedProperties(); })
.ToTable("Contacts");
}
}
Things to note about this are that first it doesn’t work yet due to some bugs and second even though EF is treating the BillToCustomerId property as an FK there
isn’t a constraint for this in the database. This is because the PK for this FK may be in one of two different tables depending on whether the relationship is to an Account or a Contact.
I think that the main problem with the workaround you show is that the EF knows nothing about the FK properties or the navigation properties.
This means that all the internal logic that reasons about relationships for loading, fixup, creating update commands, and so on is not going to take these FKs or relationships into account.
This doesn’t mean that it won’t work, but there may be unexpected behavior because of it.
Typically you can avoid exposing FKs in your model if you are willing to work with “independent associations”.
However, independent associations come with a lot of baggage and can make some things, such as working with N-Tier scenarios or doing concurrency resolution, very hard.
It’s usually best to use FK associations.
The IsIndependent methods in the relationship fluent API are used to setup a relationship as independent.
Thanks,
Arthur
