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:

• Have is ability to do something like this: Customer.CustomerAddress.OfType<MailingAddress> to get the collection of mailing addresses for the customer.
• Have a CurrentMailingAddress and CurrentBillingAddress properties, that would return the single instance CustomerAddress.OfType<> with the highest StartDate and EndDate in the future.
• Would be also nice to take Address thru Zip properties and refactor those propertiess into a Complex Type Address.

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 en开发者_如何学JAVAtity.

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

---

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.