entity-framework-4linq-to-entitiesef-database-firstdatabase-firsttable-per-hierarchy

EF4 DB-first: TPH approach?


I know this should not be trivial, but so far couldn't find the resolution...

Working with an EF4 DB-First model, using LINQ-to-Entities with POCOs which will be consumed by an MVC3 app.

I have three entities Customer, CustomerAdress and a lookup CustomerAddressType.

Customer             CustomerAddress                  CustomerAddressType
----------           ----------------                 -------------------
CustomerId (PK)      CustomerAddressId (PK)           CustomerAddressTypeId (PK)
LastName             CustomerId (FK)                  Description (Values: Mailing, Billing)
FirstName            CustomerAddressTypeId (FK) 
MiddleInitial        Address
....                 City
                     State
                     Zip
                     StartDate
                     EndDate

As you can see CustomerAddress has a FK CustomerAddressTypeId, which identifies what type of address this is, i.e. Mailing or Billing.

I would like to:

I tried creating 2 inherited entities off of CustomerAddress (assuming it is TPH [table-per-hierarchy] strategy): MailingAddress and BillingAddress, CustomerAddressTypeId being the discriminator. I did this in the model designer, and as soon as I tried adding a second inherited entity, it told me that the properties with those names already existed, and wouldn't let me rename them to match the properties of the first entity.

Any ideas how to accomplish this? Please dumb it down for me :) Thanks!!!


Solution

  • It is not such trivial. TPH will be possible but you must place all properties to the base CustomerAddress and derive two sub entities which will not hold any property because all properties are shared (= must be in the parent). You will use CustomerAddressTypeId as discriminator and because of that you will not be able to map this field as property in the entity. I'm also not sure if you can have the field both in discriminator and association mapping (that is actually nice homework for me). If not you will not be able to map association between CustomerAddress and CustomerAddressType.

    Both CurrentMailingAddress and CurrentBillingAddress are computed properties and they are not part of mapping. It is up to you to implement their logic in your partial part of Customer entity.

    I don't understand the last point with Zip and complex type.