Entity framework- Adding entities (and their navigation properties) with shared primary keys

Question

This is a simplified version of the problem I am trying to solve:

There are two entities:

Item

ItemID (PK)

Other simple properties...

WorkItem (navigation property)

WorkItem

ItemID (PK)

Other Simple Properties...

Item (Navigation property)

I need to create an Item, a WorkItem for it and I need to set both the navigation properties so the the two entities can point to each other, before saving.

This I can do:

  Item newItem = Item.CreateItem(0, blah,blah,blah);
  service.AddToItems(newItem);


  WorkItem newWorkItem = new WorkItem();           
  service.AddToWorkItems(newWorkItem);

  //set the navigation properties
  newItem.WorkItem = newWorkItem;
  newWorkItem.Item = newItem;

Unfortunately, when it comes to saving, this fails. I believe EF, when trying to set WorkItem's Item association, tries to set WorkItem's primary key.

Can anybody enlighten me as to the correct way to achieve this please?

Update:

So, I have tried building the model using inheritance. The model builds and validates.

Unfortunately, adding a WCF Data Service for my model and trying to view the service in a browser gives me this:

  ..... <m:message xml:lang="en-US">An error occurred while processing this request.    </m:message>
<m:innererror>
  <m:message>Navigation Properties are not supported on derived entity types. Entity Set 'app_Items' has a instance of type 'tempmodel.app_CostItem', which is an derived entity type and has navigation properties. Please remove all the navigation properties from type 'tempmodel.app_CostItem'.</m:message>
  <m:type>System.InvalidOperationException</m:type>
  <m:stacktrace>   at System.Data.Services.Serializers.SyndicationSerializer.WriteObjectProperties(IExpandedResult expanded, ......

CostItem being another entity, like WorkItem, which derives from Item.

score 0 · Answer 1 · answered Mar 15 '12 at 12:26

0

Based on the example you gave, I believe you should use inheritance. The WorkItem entity should inherit from the Item entity. Then, in your code, you will only need to work with a WorkItem entity and it will have all of the properties of the Item entity as well. Plus, the WorkItem entity will use the key from the Item entity.

answered Mar 15 '12 at 12:26

DCNYAM

11,966
8
53
70

Thanks for a quick reply. I Considered inheritance but, the WorkItem entity has other navigation properties not relevant to the Item. My understanding is that "sub-classes" cannot have their own navigation properties? – oldman_andy Mar 15 '12 at 12:48
Yes they can. In the past, I set up a model for invoices where InvoiceItem was the base entity. Then, I had other entities that inherited from it for each type of item. Each of those child classes had navigation properties of their own. With inheritance, the child entities do not have their own entity key -- they use the key from the base class. Therefore, in your example, you would delete the ItemID property from the WorkItem entity (in the model, not the databse). Also, they two entities cannot have properties with the same names. – DCNYAM Mar 15 '12 at 12:54
Thanks, will have a look at inheritance again. Could the inheritance behaviour vary based on the Entity generator used and the EF client library? I am trying this with default generator and silerlight client. – oldman_andy Mar 15 '12 at 13:06
I don't believe so, but I've never used Silverlight. – DCNYAM Mar 15 '12 at 13:54
It appears that it is WCF data services which doesn't support navigation properties on "sub classes" not EF – oldman_andy Mar 15 '12 at 15:11
Update from yesterday - there is a WCF Data services CTP which does support navigation properties. I have managed to get this to work but, inheritance isn't going to work anyway since I have other kinds of items and they are not mutually exclusive i.e. A WorkItem could also be a CostItem – oldman_andy Mar 16 '12 at 10:28

oldman_andy · Accepted Answer · 2012-03-29T08:45:17.570

I eneded up creating a dummy property in each of my client side partial "sub"-classes:

    private Item _BaseItem;
    [AtomIgnore]
    internal Item BaseItem
        {
        get
            {
            if (_BaseItem != null)
                return _BaseItem;
            else
                return this.Item;                
            }
        set
            {
            _BaseItem = value;
            OnPropertyChanged("Item");
            }
        }

Code on the client side uses this BaseItem property to traverse the object graph in reverse. So the code to set up the relationships now looks like this:

 Item newItem = Item.CreateItem(0, blah,blah,blah);
 service.AddToItems(newItem);


 WorkItem newWorkItem = new WorkItem();           
 service.AddToWorkItems(newWorkItem);

 //set the navigation properties
 newItem.WorkItem = newWorkItem;
 newWorkItem.**BaseItem** = newItem;

Note, the BaseItem property is declared internal; this is so that the serialiser will not attempt to serialise the property and send it to the server.

[AtomIgnore] is an attribute I created and look for in my handler for DataServiceContext.WritingEntity. The handler strips out properties marked with this attribute before they are sent to the server. This technique doesn't seem to work if the property is a ref type though, hence the use of internal.

Declaring it internal also means it cannot be bound to from XAML, fortunately i only needed to bind to a couple of properties so that work around was straightforward.

Entity framework- Adding entities (and their navigation properties) with shared primary keys

Item

WorkItem

2 Answers2