具有复合外键的实体框架导航属性

Question

EF 6.1.3.

I have a domain which contains many instances of a "Header/ Item" type pattern, where the a Header can have many Items (1 to many), and also has a "current" or "latest" item.

This is represented as follows:

Header
    Guid Id
    Guid CurrentItemId
    Item CurrentItem 
    ICollection<Item> AllItems

Item
    HeaderId
    Id

The PK of the Items is always the HeaderID + ItemID. The reason being that, by far, the most common access pattern for items is to list all items related to a given header, and having HeaderID be the first part of the PK/clustered index means we get that data with clustered index seeks.

Our problem is that when we use the CurrentItem navigation property, it only ever uses the ItemID to do the lookup, which results in not so great query plans.

I assume this is because the conventions for EF us to use the CurrentItemId to look up the CurrentItem. My question is, is there a way for my to tell EF to always perform its joins for CurrentItem by mapping the Header.Id,Header.CurrentItemId -> Item.HeaderId,Item.Id?

I believe this is a slight different scenario than the one described here: composite key as foreign key

In my case, I have a one to one mapping not one top many, and there doesn't seem to be a WithforeignKey method available for that scenario.

Answer 1

We ended up not being able to get EF to generate the SQL the way we wanted - so we wrote a db command interceptor to dynamically find instances of this join and re-write the join to match our designed composite key.

We configure this as the DbContext level like so:

    this.ModifyJoin<Item, Header>(
        (i) => new Header() { CurrentItemId = i.Id }, //What to find
        (i) => new Header() { CurerntItemId = i.Id, Id = i.HeaderId }); //What to replace with

This information is attached to the context instance itself, so when the command interceptor sees the overrides, it uses them to re-write the SQL.

This ends up working well for most scenarios, but there are some - such as when additional filtering is doing on the Item table as part of the LINQ statement, that the aliasing rules used by EF become too complex to follow without writing a full SQL parser.

For our use, this results in the ideal join about 90% of the time, which is good enough for us.

The code to do all this isn't difficult, but it's too big to put here. Add a comment if you want a copy and I'll put it up on GitHub.