Entity Framework supports composite keys. E.g., here's an entity with composite key:
public class MyEntity
{
public int NodeId { get; set; } // this is a part of entity key
public int ItemId { get; set; } // this is a part of entity key
public string Name { get; set; }
}
...its configuration for Code First approach, using fluent API:
internal sealed class MyEntityConfiguration : EntityTypeConfiguration<MyEntity>
{
public MyEntityConfiguration()
{
// this is a composite key configuration
HasKey(_ => new { _.NodeId, _.ItemId });
Property(_ => _.NodeId);
Property(_ => _.ItemId);
Property(_ => _.Name);
}
}
... and query sample:
context.MyEntities.SingleOrDefault(myEntity => myEntity.NodeId == 1 && myEntity.ItemId == 1);
What is not so good with composite keys in EF:
- you can't declare a separate type for key. Hence, if your key consists of three properties, you'll have three properties instead one key property;
- you should write your own fixup code to achieve key consistency, if changes to the existing entity's key are allowed (you can change one key property, and forget about another).
I don't know about any performance issues with EF and composite keys. I believe, that this is database engine responsibility.